Re: CONTINUATION was: #540: "jumbo" frames

David,

On Jun 27, 2014, at 3:09 AM, David Krauss <potswa@gmail.com> wrote:
> 
> On 2014–06–27, at 2:29 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> 
>> On 27/06/2014 2:22 p.m., Martin Thomson wrote:
>> 
>>> It's different with headers.  If we cap header size, then it becomes
>>> literally impossible to make some requests.
>> 
>> HTTP/1.1 header size is capped at 64KB by Squid. Other implementators
>> previously stated 4KB, 8KB and 16KB caps. What is new?
>> 
>> Ability to announce and negotiate a size will be added benefit for
>> HTTP/2 if accepted.
> 
> +1. Ignoring literally 99.98% of usage (add more 9’s for the 64K limit) is not only a mistake, it’s against the rules of any sane governing body.
> 
> Has anyone contacted the Kerberos guys? I know nothing about security but it makes sense that an authentication protocol wouldn’t worry about proxyability. Without proxies to worry about, the client can be sure that headers sent by HTTP/1 will only be received as HTTP/1, and authentication sent via HTTP/2 will only be received by a server expecting it. It becomes a non-issue.
> 
> RFC 4559 appears to cover the culprit and appears to suggest that it is MSIE. Perhaps a Microsoft rep on this list can find out whether HTTP/2 support for SPNEGO Kerberos will be needed?

As someone that has implemented RFC 4559, the only thing that is particularly proxy-unfriendly is the size of Kerberos tickets from ActiveDirectory, which is a result of having all of the group/acl stuff for a particular user account being embedded in the ticket.  We settled for supporting a maximum Authorization header size of 64k (which means we allow up to about 48k worth of ticket information Base64-encoded) - this is sufficient for most sites but we occasionally see organizations/users with larger tickets and they just break/don't work...

Unfortunately, Kerberos tickets can also only be used once, so delta compression isn't going to be any help.  Every request uses a new Authorization header value, so this (along with security concerns) is why my HTTP/2 implementation will only use the Literal Header Field Never Indexed encoding for the Authorization header.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair