Closed Bug 658960 Opened 10 years ago Closed 9 years ago
Incorrect url to HTTP OPTIONS request
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2) Gecko/20100316 Namoroka/3.6 Build Identifier: 1.0b2 The caldav sends a HTTP OPTIONS to / instead of the URL provided. Example: If URL is http://example.com/caldav/calendar/ caldav instead sends OPTIONS to http://example.com/ which is not in the same scope as the provided URL. It should be in the same scope because it may break with other services and restrictions running on the same host. Reproducible: Always Steps to Reproduce: 1. add a new caldav calendar http://example.com/caldav/calendar/ 2. 3. Actual Results: OPTIONS / HTTP/1.1 Host: example.com Expected Results: OPTIONS /caldav/calendar/ HTTP/1.1 Host: example.com none
What calendar server are you using?
The calendarserver is a part of jmail (written from scratch). The same server/hostname is also running activesync, carddav, ews and webmail. A workaround was done by replying with static options/dav-info on /, but I don't see why lightning should do this anyway since the URL is /caldav/calendar/ and not /.
I agree with Jørgen Hovland: Lightning shouldn't be expecting OPTIONS requests to random URLs outside of its configured url-space to return anything informative. If it wants to know about the server as a whole, and not about a specific resource, it should use the special URL "*" (see RFC2626 5.1.2); if it wants to know about a specific resource, it should make an OPTIONS request to that resource. For some WebDAV-specific support of this view, see RFC4918 5.2, ninth paragraph; and RFC4918 10.1.
Confirming, we should use * or avoid the call. I wonder why its even needed for webdav.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Could be fixed by patch in bug 588799. What I do not understand is why the OPTIONS request is done against a URL two dirs up from the calendar URL and not one. But probably the code changed in between. @Jørgen: Can you check current Lightning and if that does not work on its own apply the latest patch in bug 588799 and test with that?
@Jørgen: What jmail is it you are using? For jmail I find different sites describing software and services as well. An URL would be helpful. If it is a (cloud) service it would be good to be able to create an account. Thanks in advance.
Thunderbird 8 / Lightning 1.0 from november still does OPTIONS / Thunderbird won't upgrade to 1.1 and I'm not very familiar with patching .xpi-files in windows from bug 588799. I don't have a website for jmail (yet). I patched jmail when I wrote my original posting to support OPTIONS / so you won't get the error anyway. You can access my public calendar with caldav from https://email@example.com/ (its read-only) but like I said, you won't get the error unless I reverse the patch.
@Jørgen: Could you try Thunderbird and Lightning from aurora with the patch on your side removed? Use Lighning and Thunderbird from the Aurora line here: https://developer.mozilla.org/en/Calendar/Calendar_Versions Be sure to use a test profile if you do not have a full backup of all your data: http://support.mozilla.org/en-US/kb/Managing-profiles
Lightning 1.1.1 still does the same as previous versions. Tested with all of these: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124pre) Gecko/20100316 Lightning/1.0b2pre Lanikai/3.1b1 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 Lightning/1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 Lightning/1.1.1
Aurora is Lightning 1.3a2 and Thunderbird 11.0a2. Please, see https://developer.mozilla.org/en/Calendar/Calendar_Versions. In earlier versions the bug 588799 is not fixed yet. Could you try these versions? Thanks a lot.
Still the same with 1.3a2. User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0a2) Gecko/20120111 Thunderbird/11.0a2 Lightning/1.3a2 It seems that Lightning does OPTIONS on the parent path, not the root /. In my case the path is /login/ which causes options to be sent to /, but when I tested with /login/email/ it did OPTIONS /login.
If the server responds with 404 on OPTIONS with parent path OPTIONS should be retried on configured URL. We either need a full log of the interaction (preferred) or access to your unpatched server to get the failure reason. For log see bug 588799 comment 34. Logging information is also sent to process stdout which should be more easy to capture.
It works if the response is 404. The response was 500 when I tested because I just commented out some code from the request handler. Tcpdump: 15:57:04.764438 IP 126.96.36.199.49687 > 188.8.131.52.80: Flags [P.], ack 1164, win 16134, length 336 E..x .@.~.....6...:R...P..m....!P.?.."..OPTIONS / HTTP/1.1 Host: app1.mail.netclient.no User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0a2) Gecko/20120111 Thunderbird/11.0a2 Lightning/1.3a2 Accept: text/xml Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Accept-Charset: utf-8,*;q=0.1 Pragma: no-cache Cache-Control: no-cache 15:57:04.764459 IP 184.108.40.206.80 > 220.127.116.11.49687: Flags [.], ack 2455, win 2542, length 0 E..(..@.@.....:R..6..P.....!..o6P. ..... 15:57:04.766055 IP 18.104.22.168.80 > 22.214.171.124.49687: Flags [P.], ack 2455, win 2542, length 92 E.....@.@..6..:R..6..P.....!..o6P. .R...HTTP/1.1 404 Error Content-length: 27 content-type: text/plain Connection: Keep-Alive 15:57:04.960641 IP 126.96.36.199.49687 > 188.8.131.52.80: Flags [.], ack 1256, win 16111, length 0 E..( .@.~.....6...:R...P..o6...}P.>........... 15:57:04.960667 IP 184.108.40.206.80 > 220.127.116.11.49687: Flags [P.], ack 2455, win 2542, length 27 E..C..@.@..v..:R..6..P.....}..o6P. .....mail - Invalid request type 15:57:04.962591 IP 18.104.22.168.49687 > 22.214.171.124.80: Flags [P.], ack 1283, win 16104, length 385 E... .@.~.....6...:R...P..o6....P.>.9...OPTIONS /login/ HTTP/1.1 Host: app1.mail.netclient.no User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0a2) Gecko/20120111 Thunderbird/11.0a2 Lightning/1.3a2 Accept: text/xml Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Accept-Charset: utf-8,*;q=0.1 Authorization: Basic XXX Pragma: no-cache Cache-Control: no-cache 15:57:04.963511 IP 126.96.36.199.80 > 188.8.131.52.49687: Flags [P.], ack 2840, win 2729, length 255 E..'..@.@.....:R..6..P........p.P. .....HTTP/1.1 200 Ok Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL, MKCOL DAV: 1, 2, access-control, calendar-access, addressbook, extended-mkcol Connection: Keep-Alive Content-length: 0
Do I understand correctly, that everything is fine for you now with Lightning and Thunderbird from Aurora and that your CalDAV server works correctly with these versions?
Yes, everything is fine now. Thank you
Thanks for your bug report and feedback Jørgen. Marking as duplicate then.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 588799
You need to log in before you can comment on or make changes to this bug.