- From: Jason Greene <jason.greene@redhat.com>
- Date: Mon, 12 Jan 2015 09:39:15 -0600
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
> On Jan 12, 2015, at 1:13 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > > On 2015-01-12 08:06, Amos Jeffries wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 12/01/2015 7:41 p.m., Julian Reschke wrote: >>> On 2015-01-12 06:24, Amos Jeffries wrote: >>>> ... >>>>>> If you can't think of a concrete action to take based on >>>>>> this setting, I would ignore it. >>>>> >>>>> Do we have any implementations that actually do something with >>>>> this setting? >>>> >>>> Squid is. The combination of CONTINUATION frame and dense HPACK >>>> compression allows senders to allocate a headers block up past >>>> the GB *per message* size ranges. Hardware that comes with TB of >>>> RAM is pretty scarce still. ... >>> >>> >>> OK, do you we have *client* implementations doing something with >>> it. >>> >>> Let's assume a UA constructs the message and it has 8K of headers, >>> but the server has indicated it only takes 4K. What is the UA >>> supposed to do? >>> >>> a) Fail the operation immediately? b) Send the request anyway? c) >>> Try to do something to reduce size? >> >> >> Whatever it likes. The protocol has specified that the remote peer is >> probably going to reject it if delivered. The rest is a use-case >> specific implementation detail. > > 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. 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. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Monday, 12 January 2015 15:39:59 UTC