Closed Bug 1072525 Opened 10 years ago Closed 9 years ago

Interfacing with Google DAV services over HTTP/2.0 Fails with "400 Bad Request"

Categories

(Core :: Networking: HTTP, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1128038

People

(Reporter: abr, Assigned: abr)

References

Details

(Whiteboard: [spdy])

User Story

After enabling HTTP2 support (http://hg.mozilla.org/mozilla-central/rev/72f85a52a2ca), attempts to interface with Google's DAV servers has been consistently resulting in "400 Invalid Request" errors.

Attachments

(1 obsolete file)

I'm not sure when this changed, but the CardDAV importer doesn't work in
recently Nightly builds. I've tracked this down to the use of SPDY -- if
SPDY is disabled, then the import works just fine. We need to turn off
SPDY for the CardDAV importer requests.
Attachment #8494727 - Flags: review?(mdeboer)
Comment on attachment 8494727 [details] [diff] [review]
Disable SPDY for CardDAV importer

Clearing r? -- it turns out that this solution is racey, and we (almost?) always lose the race if the debugging panel isn't open. Trying to track down a solution...
Attachment #8494727 - Flags: review?(mdeboer)
Blocks: 1068950
Blocks: 1067270
Whiteboard: [spdy]
User Story: (updated)
Summary: CardDAV importer returns "400 Invalid Request" when SPDY is enabled → Interfacing with Google DAV services over HTTP/2.0 Fails with "400 Bad Request"
Component: Client → Networking: HTTP
Product: Loop → Core
QA Contact: anthony.s.hughes
I've been in contact with an engineer on Google's side, and the most recent information we have is: "Looks like the 400 response code is getting set by the backend, so the GFE isn't rejecting the request outright. I'll ping the CardDAV team to see what kind of checks they might be performing that our h2 implementation might not be respecting."

I've run some testing to make sure that the back-end isn't objecting to h2's header lowercasing, but that does not appear to be the root cause. We're waiting on a response from Google at this point, and I don't believe there's any troubleshooting we can do on our end at the moment.

If this becomes critical, a horrible hacky approach would be to disable h2 for requests with WebDAV methods bound for the "google.com" domain. I don't think this is a good idea, but wanted to mention it as a way to get unblocked if we come up against high-priority shipping deadlines.
Attachment #8494727 - Attachment is obsolete: true
I think we're making progress here -- Google stood up an experimental instance of GFE that has been configured specifically to recognize the PROPFIND method, and I now have evidence that PROPFIND succeeds against that instance where it fails against the general deployment. I'm still seeing 400 failures with REPORT, though. At this point, I suspect that it's simply the same problem with a different method.

I'll update the bug again once I know more.
Marking this as blocking b2g-2.1 as we have two existing blockers depending on it.
blocking-b2g: --- → 2.1+
Hi Adam, is there any new information on this issue?
Flags: needinfo?(adam)
(In reply to Dylan Oliver [:doliver] from comment #6)
> Hi Adam, is there any new information on this issue?

I have provided my contact at Google with a Firefox add-on that they can use to test the issue, which should help them track down the problem without relying on us to run tests whenever they adjust things on their side. Unfortunately, the GFE team is at a team summit this week, so I don't expect to see any more information from them until Friday or Monday.
Flags: needinfo?(adam)
Can we ping them again and/or are there workarounds we should pursue? We're kind of dead in the water on FxOS 2.1 Calendar right now.
Flags: needinfo?(adam)
(In reply to Dylan Oliver [:doliver] from comment #9)
> Can we ping them again and/or are there workarounds we should pursue? We're
> kind of dead in the water on FxOS 2.1 Calendar right now.

As a surprising coincidence, I just sent an email to prompt them about this topic seconds before you asked. I'll let you know what I hear back.
Flags: needinfo?(adam)
See Also: → 1082039
Dylan, are we good on unblocking this at this point ? Does not look like this is actionable by us any-how.
Flags: needinfo?(doliver)
Clearing of from blocking, please renom if there is any action to be taken on our side.
blocking-b2g: 2.1+ → ---
Passing the ni? over to Gareth who is going to investigate the current state of SPDY and report back here.
Flags: needinfo?(doliver) → needinfo?(gaye)
Depends on: 1128038
bug 1128038 provided a repro against the Google Front End and I was able to figure this was a duplicate, and my bug.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Patrick, thanks for figuring this out and fixing it. I really appreciate, and I am sure Lightning users will be thankful just as well.
Flags: needinfo?(gaye)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: