Closed Bug 1082039 Opened 8 years ago Closed 8 years ago

nsiHttpChannelInternal.allowSpdy is racy

Categories

(Core :: Networking: HTTP, defect)

32 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla36

People

(Reporter: mcmanus, Assigned: mcmanus)

References

Details

(Whiteboard: [spdy])

Attachments

(1 file)

As noted in bug 1072525 nsIHttpChannelInternal.allowSpdy is racy.

in particular, its possible a speculative connection will negotiate spdy and then get hooked up with a allowSpdy=false transaction.

The right way to fix that is to add nospdy to the conninfo hash.
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Attachment #8504149 - Flags: review?(hurley) → review+
oh sorry, seems it was caused by the push before. Re-checkedin this changes in https://treeherder.mozilla.org/ui/#/jobs?repo=mozilla-inbound&revision=c9d867500a39
https://hg.mozilla.org/mozilla-central/rev/73f9ba00bc74
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Tested with FX
Version=36.0a1
BuildID=20141024030200

A CalDAV sync with Google Calendar to get ETags is failing with Error 400 Bad Request.

Requesting GCal for a CTag has a response of Status 207 No Reason Phrase

Setting prefs 
> network.http.spdy.enabled;false
solves the problem (for the moment), all responses are correct.

(should the patch https://hg.mozilla.org/mozilla-central/rev/73f9ba00bc74 solve that problem and is it already included in FX36.0a1?)
gunter - you're seeing bug 1072525 which is believed to be a google.com problem.

this patch would allow essentially a per-channel work around if the creator of the channel wished to use it. It doesn't opt any channels into that.
You need to log in before you can comment on or make changes to this bug.