- From: David Krauss <potswa@gmail.com>
- Date: Fri, 4 Jul 2014 16:07:46 +0800
- To: Greg Wilkins <gregw@intalio.com>
- Cc: Nicholas Hurley <hurley@todesschaf.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 2014–07–04, at 3:41 PM, Greg Wilkins <gregw@intalio.com> wrote: > > David, > > I think we are talking at cross purposes! > > I'm not talking about situations that do not happen under normal conditions. For better or for worse, large cookies and big kerberos tickets are normal. > > Just sending a 32KB header is not sufficient reason to be flow controlled nor be rejected with a 420 EYC style response. If the server supports large headers, then this is perfectly allowable. I'm just saying that it should move you 32KB closer to being flow controlled (at least for frames that can be flow controlled). I’m not saying that should happen either. 32 KB closer to EYC is the same as 32 KB closer to a request flow control limit. However, the resource demands of requests aren’t the same as the resource demands of data streams. 32 KB containing 100,000 GETs generating 404’s is certainly EYC worthy. One 64 KB kerberos ticket is probably not. The purpose of flow control is to allow legitimate requests to arrive faster. Telling the user that they need to wait before requesting a page, because some PUT data is still on the wire, doesn’t make a lot of sense. Measuring requests by the kilobyte is probably overlooking what the server is really doing. In the case where legitimate headers really max out the bandwidth, that implies a lot of short-lived streams with no bodies. Raw rate limiting is already pretty much the best you can do, no?
Received on Friday, 4 July 2014 08:08:29 UTC