- From: Jason T. Greene <jason.greene@redhat.com>
- Date: Mon, 12 Jan 2015 18:44:42 -0500 (EST)
- 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