Closed Bug 658960 Opened 13 years ago Closed 13 years ago

Incorrect url to HTTP OPTIONS request

Categories

(Calendar :: Provider: CalDAV, defect)

Product:
Calendar
Component:
Provider: CalDAV
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
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
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://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.
@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: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
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 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
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: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.