RE: #540: "jumbo" frames

Yes, we are planning to coalesce.  There are two failure scenarios we consider here:

One is the stalling of the entire connection by sending a HEADERS, then *not* sending the CONTINUATION.  This is a case where a poor proxy implementation could break things if they're streaming out to the other connection.  That's actually no different with a jumbo frame, since a poorly-implemented sender could stop sending mid-frame just as easily.  Either way, if it happens on the client side, the only person affected is the sender because we won't start relaying the headers until we have the full set, and if the client wants to shoot themselves in the foot, they may.  If this happens from the back-end server, that's more painful, because the effect spreads - but if it lasts too long, our usual timeouts will cancel the blocked requests and clients will retry.  And again, the impact is localized to clients of the misbehaving server.  If servers are implemented poorly, their clients will suffer regardless of how the intermediary handles it.

The second is the fact that HEADERS can take time/throughput from DATA.  Again, this is a property of large headers, not a property of how it gets framed.  Allowing interleaving only trades out problems here -- we can't act on the headers until we have the full header set, and keeping them as a single, non-interleaved unit reduces the need to buffer and wait for the rest to show up at some point in the future.  We'd rather deal with brief HOLB while the full set arrives (in the rare case that it's large) than have a partial header set in memory that we can't deliver to the app yet.

In either case, we have to support large headers, and the drawbacks between a HEADERS+CONTINUATION chain and a single larger HEADERS frame are the same.  At the same time, there is deployment data already discussed which argues against spreading the larger frame size to DATA.  The churn doesn't appear to buy anything, so we prefer stability.

I understand the desire for more predictability, though -- defining settings (in spec or via an extension) that allow a server to inform clients what size individual or total header will result in rejection isn't a bad idea.  Others have expressed a desire not to publish their limits to misbehaving clients, however.

-----Original Message-----
From: Jason Greene [mailto:jason.greene@redhat.com] 
Sent: Friday, June 27, 2014 1:12 PM
To: Mike Bishop
Cc: Michael Sweet; Greg Wilkins; Mark Nottingham; HTTP Working Group
Subject: Re: #540: "jumbo" frames


On Jun 27, 2014, at 12:12 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

> Microsoft will be supporting headers larger than 16k in both our clients (IE and other apps) and server (IIS).  One reason is that a large number of our enterprise customer have Active Directory integrated solutions for authentication and authorization.  AD uses Kerberos as the preferred authentication mechanism and the authentication tokens can grow quite large.  IIS used to have a default maximum header size of 16k, but we have had to increase this to 64k in recent releases.  This is just one reason for a need to implement large headers.
>  
> We have been following the debate here in the WG and as implementers of a browser, an application platform, a web server, and a forward proxy, we do not see a tangible difference between the proposals.  Therefore, our opinion is that there is no reason to delay WGLC to make a major design change at this stage.
>  

Hi Mike, 

I hope you don't mind a follow-up, since you plan to use this capability. Does IIS have plans to coalesce connections when acting as a proxy, and if so are you not concerned with the HOL blocking issues that will occur with the current behavior of CONTINUATIONS? 

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

Received on Friday, 27 June 2014 23:06:23 UTC