- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 12 Jan 2015 16:52:30 +0100
- To: Jason Greene <jason.greene@redhat.com>
- CC: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
On 2015-01-12 16:39, Jason Greene wrote: > ... >> 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. The interop problem is caused by the fact that servers may vary in behavior (maybe signalling a lower value than required and accepting more headers in practice), and so can clients (trying requests even though the SETTINGS indicate that it won't work, and then getting away with it). > 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. 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. Maybe this is another case where more explanation would be helpful. Best regards, Julian
Received on Monday, 12 January 2015 15:53:22 UTC