652308 - Implement HSTS-like pipelining opt-in for HTTPS connections

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, enhancement)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

With HSTS, you can have an HTTP header field on a HTTPS connection like:

    Strict-Transport-Security: max-age=31536000

which will tell the browser to enable Strict-Transport-Security for one year for the site. We should have a similar opt-in mechanism that we cache in order to immediately pipeline all requests to that server (i.e. without waiting for the first response to come back and/or doing any heuristic checks or pretest), and regardless of whether pipelining is otherwise enabled.

Comment 1

[Honza Bambas (:mayhemer)]

This should also include a mechanism to switch pipelining off immediately when a problem is found also e.g. after an infrastructure has changed.

IMO there should just be a header that we do not cache that explicitly tells the browser to use or not to use pipelining (isn't there a bug or spec already?).

Also, what should site admins do when problems happen only with Firefox but all other browsers work well?  Should they switch the header flag just for our user agent?  Maybe...

Why to limit this just to HTTPS connections?

Why to use mechanics similar to HSTS when we can just add a header to all/index pages requests?

Comment 2

[Patrick McManus [:mcmanus]]

(In reply to comment #0)
> With HSTS, you can have an HTTP header field on a HTTPS connection like:
> 
>     Strict-Transport-Security: max-age=31536000
> 
> which will tell the browser to enable Strict-Transport-Security for one year
> for the site. We should have a similar opt-in mechanism that we cache in order
> to immediately pipeline all requests to that server (i.e. without waiting for
> the first response to come back and/or doing any heuristic checks or pretest),
> and regardless of whether pipelining is otherwise enabled.

This proposal basically boils down to allowing a HTTPS based server to opt-in to what I call aggressive mode. (There is a pref for aggressive mode already implemented in the patch series). Aggressive mode basically means that instead of wading slowing into pipelining with a particular server, we open the floodgates immediately upon detecting a validly configured server.

Aggressive mode does not equal "stupid mode" - if we encounter problems we will still back off. I don't see a reason to allow a server to insist we pipeline even in the presence of observed problems.

A couple nits - placing this in a response header can't save a round trip before enabling pipelining because of an obvious chicken and egg problem. Saying to cache this header to save future round trips is more or less the same as saying cache the intersection of the http response version and our server blacklist for this hostname - which the patch series already does.

The other nit is that there is no per-server pre-test. There is a client location pre-test. (hopefully to be per topology if we get hooks for that). Obviously a server can't opt you out of something that does not operate on per server scope.

I'm not a big fan of opt-in for this feature. However I do want to move towards "aggressive" everywhere, not just HTTPS, I just want to do it in increments as we get experience with each stage. This might provide a hook to help with that transition and that's good.

But remember "test the waters" is just a state that we store persistently. Presumably sites you frequent often have met the test and you don't relearn that information everytime.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to comment #2)
> I'm not a big fan of opt-in for this feature. However I do want to
> move towards "aggressive" everywhere, not just HTTPS, I just want
> to do it in increments as we get experience with each stage. This
> might provide a hook to help with that transition and that's good.

Right. The goal is to allow a website to opt in to the "aggressive mode" ASAP, before we've implemented pre-test and other pipelining prerequisites. That's why I propose it for HTTPS only, and also why I propose it to be opt-in. This and TLS compression should get us closer to SPDY-like performance for websites that support it, with minimal changes, before we implement SPDY.

The original version of this proposal was to put the opt-in in the TLS handshake, so that we could always avoid a round-trip, and pipeline all the requests and subrequests for a page in the initial application data segment. Also, with the TLS handshake extension we could be sure (as can be) that the load balancer itself was opting in, and not the web server, so we wouldn't have to worry about the possibility of any intermediary network equipment messing up pipelining. I am still planning to propose the TLS extension, but deployment of a TLS extension would be slow, so this is an attempt at a more pragmatic alternative.

Comment 4

[Patrick McManus [:mcmanus]]

(In reply to comment #3)

> Right. The goal is to allow a website to opt in to the "aggressive mode" ASAP,

Do you mean before/instead of merging the rest of the patchset? I'm not on board with that. Those are, imo, necessary changes particularly wrt HOL blocking.

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to comment #4)
> Do you mean before/instead of merging the rest of the patchset? I'm not on
> board with that. Those are, imo, necessary changes particularly wrt HOL
> blocking.

Definitely not "instead of" or "before." I am not sure if all the pipelining patches are necessarily prerequisites to doing something like this, but no doubt some (most?) of them are. Definitely, the possible negative effects of LSPs and LSP-like hooks into our HTTP parser (on the decrypted side of the HTTPS connection) would need to be taken into account for this mechanism to be safe, at least.

Comment 6

[Patrick McManus [:mcmanus]]

> Definitely not "instead of" or "before." I am not sure if all the pipelining
> patches are necessarily prerequisites to doing something like this, but no
> doubt some (most?) of them are.

agreed - cool!

Comment 7

[Patrick McManus [:mcmanus]]

more likely to remove pipeline code than make it sticky. h2 is the way.