Closed
Bug 658960
Opened 14 years ago
Closed 13 years ago
Incorrect url to HTTP OPTIONS request
Categories
(Calendar :: Provider: CalDAV, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 588799
People
(Reporter: bugzilla.mozilla.org, Unassigned)
Details
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
Comment 1•14 years ago
|
||
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.
Comment 4•13 years ago
|
||
Confirming, we should use * or avoid the call. I wonder why its even needed for webdav.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•13 years ago
|
||
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?
Comment 7•13 years ago
|
||
@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://mail.netclient.no/public/jh@netclient.no/ (its read-only) but like I said, you won't get the error unless I reverse the patch.
Comment 9•13 years ago
|
||
@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
Reporter | ||
Comment 10•13 years ago
|
||
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:1.9.2.2pre) 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
Comment 11•13 years ago
|
||
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.
Reporter | ||
Comment 12•13 years ago
|
||
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.
Comment 13•13 years ago
|
||
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.
Reporter | ||
Comment 14•13 years ago
|
||
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 213.179.54.202.49687 > 213.179.58.82.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 213.179.58.82.80 > 213.179.54.202.49687: Flags [.], ack 2455, win 2542, length 0
E..(..@.@.....:R..6..P.....!..o6P. .....
15:57:04.766055 IP 213.179.58.82.80 > 213.179.54.202.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 213.179.54.202.49687 > 213.179.58.82.80: Flags [.], ack 1256, win 16111, length 0
E..( .@.~.....6...:R...P..o6...}P.>...........
15:57:04.960667 IP 213.179.58.82.80 > 213.179.54.202.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 213.179.54.202.49687 > 213.179.58.82.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 213.179.58.82.80 > 213.179.54.202.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
Comment 15•13 years ago
|
||
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?
Reporter | ||
Comment 16•13 years ago
|
||
Yes, everything is fine now. Thank you
Comment 17•13 years ago
|
||
Thanks for your bug report and feedback Jørgen.
Marking as duplicate then.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•