Re: Limiting allowable pre-SETTINGS requests

On Jun 6, 2014, at 6:14 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 6/06/2014 10:28 a.m., David Krauss wrote:
>> 
>> Four kilobytes should be plenty for a proxy to route a stream and
>> relieve the buffering pressure by streaming as HPACK was designed to
>> do, but someone mentioned proxies peeking at cookies too. It seems
>> that we need a closer look at what kind of implementation handles
>> which specific use case. These issues aren’t specific to extra-simple
>> servers.
> 
> FWIW the only use-cases I've seen for proxies to peek at Cookie was for
> interception proxies to authenticate despite the client-side security
> measures, or for load balancers to ensure end-to-end pinning of user
> sessions (forcing statefulness on the stateless transfer protocol).
> The WG has decided to ignore interception middleware entirely.
> The Load-balancer use-case is apparently resolved by "just use HTTP/1.1”.

Really? I find that perspective surprising. That’s basically saying that any website that needs state and redundancy is better off not using HTTP/2.

Granted I don’t think that situation is all that dire. LBs will likely still support the new protocol even if it is more expensive to process. Of course, if the penalty is too high, it could certainly impact adoption.

> 
> Maybe someone has another use case for accessing Cookie but I think the
> Load-Balancer case served fine by an HTTP/2 extension between the LB and
> the backend servers - provided we are allowed extension frames (or maybe
> despite HTTP/2 spec).

That doesn’t really help because it’s the request needs to be pinned, and not aspects of the wire. The client could lose and reestablish a new connection and a new stream, and send another request on the same session, and it needs to go to the right place.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Friday, 6 June 2014 19:40:27 UTC