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

> On Jan 12, 2015, at 3:31 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On 12 January 2015 at 07:52, Julian Reschke <julian.reschke@gmx.de> wrote:
>>> 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.
> 
> Request size is not really a negotiable or flexible property.  Often,
> a request is a request is a request.  If you have to include Foo: bar,
> then you have to include Foo: bar.  The only alternative is to fail,
> but as long as the risk of failure is non-trivial, there is a strong
> incentive to send anyway.
> 
> In a browser at least, the primary contributor to header field size is
> the server: long request URIs and cookies usually come from the
> server, so they won't do anything special here (the actual baseline
> being low enough that it isn't worth checking).  

Wouldn't it be useful for a browser's XHR implementation? That way just the respective bit of JS fails (with a handleable error) as opposed to potentially interfering with other resources being loaded on the same connection.

> In a custom client,
> there may be some cases where this makes sense to respect, but people
> use HTTP for too many things to say for sure.  The intermediary case
> is easy (the primary reason for the inclusion of the setting, if I
> recall.
> 

Received on Monday, 12 January 2015 23:45:33 UTC