Cannot load certain https site using SPDY and HTTP/2 proxy

RESOLVED FIXED in Firefox 37



4 years ago
4 years ago


(Reporter: tatsuhiro.t, Assigned: mcmanus)


Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox36 wontfix, firefox37 fixed, firefox38 fixed)


(Whiteboard: [spdy])


(2 attachments)



4 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.91 Safari/537.36

Steps to reproduce:

1. Set up SPDY or HTTP/2 secure proxy (node-spdyproxy or nghttpx + squid)
2. Instruct Firefox nightly to use the secure proxy
3. Navigate to

Actual results:

The web page was not fully loaded.  From network developer tool attached in Firefox, some resources (e.g., js) were not loaded.  It just logged Request headers, and no Response headers.  It seems cleartext http site does not exhibit this issue.  Only several https sites I observed this issue.  Meanwhile,,, are all fine.
If we negotiate http/1.1 between firefox and proxy, site is fully rendered correctly.  If spdy/3.1 or h2-16 (h2-14) is negotiated between firefox and proxy, we have this issue.

Expected results:

Web site should be fully loaded normally.
Component: Untriaged → Networking: HTTP
Product: Firefox → Core

Comment 1

4 years ago
I can confirm it. Weirdly the troubled resources appear to be on the origin itself which is running h1 (inside the spdy tunnel).. the usual tricky cases involve spdy/h2 inside spdy/h2, which seems to be working fine.
Whiteboard: [spdy]

Comment 2

4 years ago
I see similar behaviour at where everything loads perfectly and quickly aside from the stylesheets. The request appears to be made, but the stylesheets are never loaded.

No page rendering is done while waiting for these files to load, either. Once I stop page loading, I am shown the unstyled page.

Requesting the CSS files directly loads them just fine; a subsequent browse to the site loads them just fine from cache.


Comment 3

4 years ago
Sorry, just noticed this bug relates to viewing through a proxy. Disregard, as I am not on a proxy server. Apologies for the bug spam.

Comment 4

4 years ago
we get into a state where we choose not to make another h2 CONNECT tunnel to (h1 is carried inside), because we have 6 of them already open (all inside the single h2 connection to the proxy).. and then is sometimes returning h1 responses with "connection closed", which tears down those tunnels instead of making them eligible for reuse.. there is a race condition in there somewhere where we don't notice and then establish a new tunnel.

Comment 5

4 years ago
Attachment #8566648 - Flags: review?(hurley)


4 years ago
Assignee: nobody → mcmanus
Ever confirmed: true

Comment 7

4 years ago

patch 1 is just a bunch of housekeeping.. enhanced logging that let me track down the problem and removal of some old allocation failure checks from the days before infallible new.

patch 2 is the bugfix.


4 years ago
Attachment #8566648 - Flags: review?(hurley) → review+

Comment 8

4 years ago
Comment on attachment 8566649 [details] [diff] [review]
https tunnel of h1 without pconn inside h2 session stall (2 of 2)

Review of attachment 8566649 [details] [diff] [review]:

Just a few nits

::: netwerk/protocol/http/Http2Session.cpp
@@ +3328,5 @@
> +{
> +  MOZ_ASSERT(PR_GetCurrentThread() == gSocketThread);
> +  nsHttpTransaction *trans = aHttpTransaction->QueryHttpTransaction();
> +  LOG(("Http2Session::MaybeReTunnel %p trans=%p\n", this, trans));
> +  nsHttpConnectionInfo *ci = aHttpTransaction->ConnectionInfo();

move this down closer to where it's used.

::: netwerk/protocol/http/SpdySession31.cpp
@@ +2713,5 @@
>  void
> +SpdySession31::CreateTunnel(nsHttpTransaction *trans,
> +                            nsHttpConnectionInfo *ci,
> +                            nsIInterfaceRequestor *aCallbacks) 

nit: trailing whitespace

@@ +2768,5 @@
> +{
> +  MOZ_ASSERT(PR_GetCurrentThread() == gSocketThread);
> +  nsHttpTransaction *trans = aHttpTransaction->QueryHttpTransaction();
> +  LOG(("SpdySession31::MaybeReTunnel %p trans=%p\n", this, trans));
> +  nsHttpConnectionInfo *ci = aHttpTransaction->ConnectionInfo();

move closer to use

::: netwerk/protocol/http/nsHttpTransaction.h
@@ +407,5 @@
>  private:
>      uint32_t mClassOfService;
> +
> +public:
> +    // setting mDontRouteViaWildCard to true means the transaction should only

comment needs rewording, since we no longer have mDontRouteViaWildCard :)
Attachment #8566649 - Flags: review?(hurley) → review+
Last Resolved: 4 years ago
status-firefox38: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla38

Comment 11

4 years ago
I confirmed this issue was fixed with latest nightly.  Awesome, guys.  Thank you very much.


4 years ago
Blocks: 378637
status-firefox36: --- → wontfix
status-firefox37: --- → affected

Comment 12

4 years ago
Comment on attachment 8566649 [details] [diff] [review]
https tunnel of h1 without pconn inside h2 session stall (2 of 2)

I am asking for approval gecko-37. I marked that beta but the channels are about to change versions, so it's confusing.

This is a bug in a feature that shipped as part of 33. It can lead to serious stalls when browsing when using HTTPS proxying - its good to backport the fix one interval.

Approval Request Comment
[Feature/regressing bug #]:https proxying (feature 378637)
[User impact if declined]: some origins will have resources intermittently fail to load when proxying over https - that feature landed in ff33
[Describe test coverage new/current, TreeHerder]: fix confirmed by reporter
[Risks and why]: its not a big patch, but we don't have automated proxy testing coverage in general beyond a few trivial things. It has been tested and confirmed by the reporter
[String/UUID change made/needed]: none
Attachment #8566649 - Flags: approval-mozilla-beta?
Comment on attachment 8566649 [details] [diff] [review]
https tunnel of h1 without pconn inside h2 session stall (2 of 2)

This is a larger patch than I normally like to take on Beta but the fix has been on m-c for 6 days and the submitter has verified the fix (comment 11) in Nightly. Let's take this fix for Beta 2. Beta+
Attachment #8566649 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify-
You need to log in before you can comment on or make changes to this bug.