SETTINGS_MAX_HEADER_LIST_SIZE, was: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

On 2015-01-12 16:39, Jason Greene wrote:
> ...
>> I see lots of opportunities for interop problems here,
>
> With or without the setting, a server or intermediary is not guaranteed to send a 431. A constrained server/intermediary is unlikely to want to spend CPU/memory to process excessive header blocks, and since the compression context is invalid without doing so, GOAWAY/hangup is likely. So I fail to see how this creates any *new* interop problems. It only provides extra information that can be used to avoid poor behavior.

The interop problem is caused by the fact that servers may vary in 
behavior (maybe signalling a lower value than required and accepting 
more headers in practice), and so can clients (trying requests even 
though the SETTINGS indicate that it won't work, and then getting away 
with it).

> It’s particularly useful to intermediaries that are coalescing multiple client connections to a single origin server. Without this information, one bad actor can effectively lead to the termination of a connection in use by many good actors. With the information, the intermediary can ensure it never forwards such requests, leaving the failure to the bad actor.
>
>> unless we either remove this or make it stricter, for instance when popular servers/services reporting a maximum header size that is below of what they actually accept in practice, thus there'll be an incentive to ignore it to avoid unnecessary client-visible errors.
>
> The possibility of losing your connection is a pretty strong incentive IMO.

I agree that this is useful for intermediaries. I still don't how it 
would help UAs in any way, because they really have no incentive not to 
try anyway.

Maybe this is another case where more explanation would be helpful.

Best regards, Julian

Received on Monday, 12 January 2015 15:53:22 UTC