[go: up one dir, main page]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Incompatibility with Cyrus / Fastmail #166

Open
jtagcat opened this issue Jul 8, 2024 · 4 comments
Open

Incompatibility with Cyrus / Fastmail #166

jtagcat opened this issue Jul 8, 2024 · 4 comments

Comments

@jtagcat
Copy link
jtagcat commented Jul 8, 2024 •
edited
Loading

Related: #68

https://github.com/jtagcat/calredact/blob/6c12f21a34d440c4633859c171da24d62495eed3/main.go#L106-L115
Tested faulty with fastmail.com (Cyrus). Same generated request works (207) on OX App Suite and Nextcloud.

Code in question: https://github.com/jtagcat/calredact/blob/6c12f21a34d440c4633859c171da24d62495eed3/main.go#L106-L115

Response for go-webdav on fastmail.com:

HTTP/1.1 400 Bad Request
Server: nginx
Date: Mon, 08 Jul 2024 18:25:32 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 491
Connection: keep-alive
Vary: Accept-Encoding
X-Frontend: frontend1
X-Trace-Id: ti_72b00284f07bc0d6f468732a01304fd4

<!DOCTYPE html>
<html style='color-scheme:dark light'>
  <head>
    <title>400 Bad Request</title>
  </head>
  <body>
    <h1>Bad Request</h1>
    <p>The request was not understood by this server.</p>
    <hr>
    <address>Cyrus-HTTP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb Cyrus-SASL/2.1.27 Lib/XML2.9.10 Jansson/2.14 OpenSSL/1.1.1w Wslay/1.1.1 Zlib/1.2.11 Xapian/1.5.0 LibiCal/3.1 ICU4C/74.2 SQLite/3.34.1 Server at caldav.fastmail.com Port 2275</address>
  </body>
</html>

Response for patched request:

HTTP/1.1 207 Multi-Status
Server: nginx
Date: Mon, 08 Jul 2024 18:19:52 GMT
Content-Type: application/xml; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding, Brief, Prefer
X-Frontend: frontend1
X-Trace-Id: ti_cc0dac5f325d8344d7401cd5217ce56d
Content-Length: 648

<?xml version="1.0" encoding="utf-8"?>
<d:multistatus xmlns:c="urn:ietf:params:xml:ns:caldav" xmlns:d="DAV:">
  <d:response>
    <d:href>/dav/calendars/user/calretest@fastmail.com/5B895624-3D36-11EF-B5BC-83625697A2A5/e5213f54-a17a-403f-90b5-83919b5ef783.ics</d:href>
    <d:propstat>
      <d:prop>
        <c:calendar-data><![CDATA[BEGIN:VCALENDAR
END:VCALENDAR
]]></c:calendar-data>
        <d:getlastmodified>Mon, 08 Jul 2024 16:33:15 GMT</d:getlastmodified>
        <d:getetag>"70e4896a60aabe57ad32610e9b090bf7b5257208"</d:getetag>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

Requests (left: generated, right: patched):
image

It appears that the primary incompatibility is the d: and c:/:c syntax. I'm a mere consumer, not familiar with the RFCs. Is this an issue with go-webdav or Cyrus?

I based the patch on Cyrus source + proxying Thunderbird traffic as well.
@jtagcat jtagcat mentioned this issue Jul 8, 2024
Closed
@emersion
Copy link
Owner
emersion commented Jul 8, 2024

Hm. In theory the xmlns things should be equivalent.

There are other differences, e.g. name attributes. Does it work if you leave the xmlns attrs as-is, but use the fixed up name attrs?

@jtagcat
Copy link
Author
jtagcat commented Jul 9, 2024

Hm. In theory the xmlns things should be equivalent.

There are other differences, e.g. name attributes. Does it work if you leave the xmlns attrs as-is, but use the fixed up name attrs?

No. I'll note, that in Cyrus source, the xmlns was treated to be inherited — duplicating it in children seems not necessary.

@emersion
Copy link
Owner
emersion commented Jul 9, 2024

Yeah, but given the design of the encoding/xml package, this is what we end up with.

@dilyanpalauzov
Copy link

You can upload the faulty request as text towards Cyrus IMAP — https://github.com/cyrusimap/cyrus-imapd/issues/ (more or less this is Fastmail). Typing the request from the image, in order to reproduce the problem, is cumbersome and error prone. Apart from namespaces, left and right requests have other differences - in the first comp-filter one request has VEVENT, the other VCALENDAR; one comp-element has empty name=, the other has name=VCALENDAR.

It is not clear from the screenshot with the requests provided here, whether the namespaces are the problem, or the other differences cause the failure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@emersion @dilyanpalauzov @jtagcat