- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 12 Jan 2015 13:27:01 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Jason Greene <jason.greene@redhat.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
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). 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 21:27:28 UTC