RE: #540: "jumbo" frames

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.

From: Michael Sweet [mailto:msweet@apple.com]
Sent: Friday, June 27, 2014 9:45 AM
To: Greg Wilkins
Cc: Mark Nottingham; HTTP Working Group
Subject: Re: #540: "jumbo" frames

FWIW, my current HTTP/2 implementation does not support continuation headers, for the simple reason that 99.9999% of our users do not need extremely large header support (for ActiveDirectory/RFC 4559 deployments).


On Jun 27, 2014, at 3:17 AM, Greg Wilkins <gregw@intalio.com<mailto:gregw@intalio.com>> wrote:


I accept that the WG probably has to move on and that we can't iterate on this argument forever.

But please don't say there has been convergence.   Several implementors have spoken here saying that they will not support continuations, so the current draft rather than supporting arbitrary large headers has actually enforced even worse support for them in deployed implementations.


On 27 June 2014 09:07, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:
I think this discussion has converged upon not making any changes to the HTTP/2 spec, but allowing experimentation to take place in a "jumbo" extension.

As such, I'm going to close the issue. If implementation and deployment experience in the next round leads us to think differently, we can revisit the question, of course.

Cheers,

P.S. If anyone wants to launch an extension draft, please say so; I'm happy to coordinate that through the WG.





--
Mark Nottingham   https://www.mnot.net/







--
Greg Wilkins <gregw@intalio.com<mailto:gregw@intalio.com>>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com<http://www.webtide.com/>  advice and support for jetty and cometd.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair