Closed
Bug 727943
Opened 14 years ago
Closed 14 years ago
Accessing Google Calendar via CalDAV protocol in Lightning is broken with SPDY
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
FIXED
mozilla13
People
(Reporter: ssitter, Assigned: mcmanus)
References
Details
(Keywords: regression, Whiteboard: [spdy])
Attachments
(1 file)
|
2.21 KB,
patch
|
mayhemer
:
review+
|
Details | Diff | Splinter Review |
Accessing Google Calendar via CalDAV Provider is broken in current Thunderbird 13.0a1 nightly builds. Calendar will be marked as not available.
Using Lightning 1.5a1 (BuildID: 20120216041923) I observed the following regression range:
Works: Mozilla/5.0 (Windows NT 6.1; rv:13.0a1) Gecko/20120208 Thunderbird/13.0a1 (Build ID: 20120208030040)
Fails: Mozilla/5.0 (Windows NT 6.1; rv:13.0a1) Gecko/20120209 Thunderbird/13.0a1 (Build ID: 20120209090229)
Checkins during regression range:
=================================
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4b9608fd670c&tochange=fe7a433de8ff
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=8dfd634cfb27&tochange=e63a3641c3d4
Console output:
===============
CalDAV: send: <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:prop>
<D:resourcetype/>
<D:owner/>
<D:supported-report-set/>
<C:supported-calendar-component-set/>
<CS:getctag/>
</D:prop>
</D:propfind>
CalDAV: Status 400 on initial PROPFIND for calendar Google Calendar
CalDAV: Authentication scheme for Google Calendar is Basic
CalDAV: recv: <!DOCTYPE html>
<html lang=en>
<meta charset=utf-8>
<meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
<title>Error 400 (Bad Request)!!1</title>
<style>
*{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}
</style>
<a href=//www.google.com/><img src=//www.google.com/images/errors/logo_sm.gif alt=Google></a>
<p><b>400.</b> <ins>That’s an error.</ins>
<p>Your client has issued a malformed or illegal request. <ins>That’s all we know.</ins>
Warning: There has been an error reading data for calendar: Google Calendar. However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_NOT_DAV. Description: The resource at https://www.google.com/calendar/dav/[...]/events is either not a DAV collection or not available
Warning: There has been an error reading data for calendar: Google Calendar. However, this error is believed to be minor, so the program will attempt to continue. Error code: READ_FAILED. Description:
|
Reporter | |
Comment 1•14 years ago
|
||
It seems to be caused by enabling SPDY (Bug 724563).
It works fine again if I set "network.http.spdy.enabled" to "false".
Summary: Accessing Google Calendar via CalDAV Provider is broken [CalDAV: Status 400 on initial PROPFIND] → Accessing Google Calendar via CalDAV Provider is broken with SPDY [CalDAV: Status 400 on initial PROPFIND]
|
Assignee | |
Comment 2•14 years ago
|
||
I'm not familiar with caldav or lightning.. can you provide pointers?
|
|
Reporter | |
Comment 3•14 years ago
|
||
Lightning (https://www.mozilla.org/projects/calendar/lightning/) is a calendaring extension for Thunderbird and SeaMonkey. Nightly builds can be found at https://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-central/
The instructions on how to setup access to Google Calendar using the CalDAV protocol can be found at https://support.google.com/calendar/bin/answer.py?hl=en&answer=99358#sunbird
Source code is at http://mxr.mozilla.org/comm-central/source/calendar/providers/caldav/
|
|
Assignee | |
Comment 4•14 years ago
|
||
thanks stefan. I'll look into it.
|
||
Comment 6•14 years ago
|
||
(In reply to Stefan Sitter from comment #3)
> The instructions on how to setup access to Google Calendar using the CalDAV
The quickie answer is:
Location = https://www.google.com/calendar/dav/[YourGMailAddress]/events
|
||
Comment 7•14 years ago
|
||
Time for a round of thank you's, some great collaboration here:
Stefan, thank you very much for the great analysis where this problem comes from.
Peter, thanks for reporting this issue and giving the initial hint.
Patrick, thanks in advance for finding out whats going wrong here.
|
|
Assignee | |
Comment 8•14 years ago
|
||
the issue was that the internal http<>spdy request conversion code assumed non-core http methods didn't have message bodies and propfind (among others probably) do. Patch forthcoming.
I was skeptical that google was actually providing spdy services for caldav, but they are (I'm not sure if they know it either) :).. and I suspect lightning is the world's first spdy caldav client.
I do have to note, however, that lightning was completely unusable for me when I tried to hook it up to my normal gcal calendar. That calendar is 5 years old and has thousands of events. The main thread just spun and spun for long periods, it took me 5 minutes just to dismiss a reminder box that came up with hundreds of old events. Insanely painful - eventually I just had to make a new profile with a new gcal account to troubleshoot this bug. That worked fine.
Status: NEW → ASSIGNED
Whiteboard: [spdy]
|
|
Assignee | |
Comment 9•14 years ago
|
||
Assignee: nobody → mcmanus
Attachment #598350 -
Flags: review?(honzab.moz)
|
|
Reporter | |
Updated•14 years ago
|
Component: Provider: CalDAV → Networking: HTTP
OS: Windows 7 → All
Product: Calendar → Core
QA Contact: caldav-provider → networking.http
Hardware: x86 → All
Summary: Accessing Google Calendar via CalDAV Provider is broken with SPDY [CalDAV: Status 400 on initial PROPFIND] → Accessing Google Calendar via CalDAV protocol in Lightning is broken with SPDY
Version: Lightning 1.5 → 13 Branch
|
||
Comment 10•14 years ago
|
||
Comment on attachment 598350 [details] [diff] [review]
patch 0
Review of attachment 598350 [details] [diff] [review]:
-----------------------------------------------------------------
I have to say that one empty body and two duplicates are unusual :) But I got understanding what it does easily at the first look.
r=honzab
Attachment #598350 -
Flags: review?(honzab.moz) → review+
|
|
Assignee | |
Comment 11•14 years ago
|
||
Target Milestone: --- → mozilla13
|
|
||
Comment 12•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
|
||
Comment 13•11 years ago
|
||
With Reminderfox it seems we are the second(?) CalDAV calendar running into the SPDY problem.
Working with Google Calendar is was no problem until Firefox 33 or Thunderbird 33.
After upgrading to FX34/Nightly sync with Google Calendar failed with similar error described by Stefan before
(see comments https://bugzilla.mozilla.org/show_bug.cgi?id=727943#c0)
Confirming
> It works fine again if I set "network.http.spdy.enabled" to "false".
also here.
A FX34 snippet of a REPORT request "network.http.spdy.enabled" to "true".:
> PROPFIND https://www.googleapis.com/caldav/v2/username%40gmail.com/events/
> Authorization: Bearer ya29.qABfXXa.........szm49koY-
> Depth: 0
> Content-Type: application/xml
> <d:propfind xmlns:d="DAV:" xmlns:cs="http://calendarserver.org/ns/">
> <d:prop>
> <d:displayname />
> <cs:getctag />
> </d:prop>
> </d:propfind>
>
> -- response --
> 207 No Reason Phrase
> Alternate-Protocol: 443:quic,p=0.01
> Cache-Control: private, max-age=0
> Content-Encoding: gzip
> Content-Length: 346
> Content-Type: text/xml; charset=UTF-8
> Date: Fri, 24 Oct 2014 02:07:15 GMT
> Expires: Fri, 24 Oct 2014 02:07:15 GMT
> Server: GSE
> Vary: Origin, Referer, X-Origin
> x-content-type-options: nosniff
> X-Frame-Options: SAMEORIGIN
> X-XSS-Protection: 1; mode=block
> X-Firefox-Spdy: h2-14
On FX34 setting "network.http.spdy.enabled" to "false" with the same request:
> -- response --
> 207 Multi-Status
> Vary: Origin, Referer, X-Origin
> Content-Type: text/xml; charset=UTF-8
> Content-Encoding: gzip
> Date: Fri, 24 Oct 2014 02:47:49 GMT
> Expires: Fri, 24 Oct 2014 02:47:49 GMT
> Cache-Control: private, max-age=0
> x-content-type-options: nosniff
> X-Frame-Options: SAMEORIGIN
> X-XSS-Protection: 1; mode=block
> Server: GSE
> Alternate-Protocol: 443:quic,p=0.01
> Transfer-Encoding: chunked
So NO **X-Firefox-Spdy** is returned!
Another observation:
the FF 34 response header is slightly different:
> X-Firefox-Spdy: h2-14
versus FF 33:
> X-Firefox-Spdy: 3.1
Because setting "network.http.spdy.enabled" to "false" may limit some other communication feature this can't be the final solution.
>> Need to reopen this bug?!
|
|
Assignee | |
Comment 14•11 years ago
|
||
you're bumping into 1072525 - which is believed to be a google.com problem with DAV and their h2 implementation
You need to log in
before you can comment on or make changes to this bug.
Description
•