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