W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

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

From: Jason T. Greene <jason.greene@redhat.com>
Date: Mon, 12 Jan 2015 18:44:42 -0500 (EST)
Message-Id: <480B37AF-4DDD-43C6-9F0B-B9E8E86C064E@redhat.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>

> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:42 UTC