W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Our Schedule

From: David Krauss <potswa@gmail.com>
Date: Wed, 28 May 2014 23:24:59 +0800
Cc: Greg Wilkins <gregw@intalio.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <49B2F48C-6A48-4BAC-BA09-828B6D88CED6@gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>

On 2014–05–28, at 8:21 PM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:

> ​ENHANCE_YOU_CALM is suggested in the another thread.

The client sends an innocuous, small request to the origin via a proxy. The origin sends too many headers back. So, the proxy tells the client to ENHANCE_YOUR_CALM?

I see you’re working on a reverse proxy. Can you please comment on my other question:

>> What if the header stream takes too long, without being particularly large? Then the problem is not too many headers at all. Indeed, for a reverse proxy with a slow client, this is sure to happen as sure as streaming kicks in at all.
>> ​This is not limited to HEADERS.  Just send 1 byte of first header of any frame and pause.​
>> ​This is good candidate for the timeout, isn't it?​
> I’m talking about the connection between the reverse proxy and the server. There should be only one connection there, representing all the clients assigned to the server. The reverse proxy is trusted, and it can always send complete data frames. However it is still at the mercy of the client as for complete header blocks, under a streaming policy.

If nothing can be done about this, HTTP/2 reverse proxies would seem to be bound to multi-connection topology with respect to the upstream servers. Perhaps not a step backwards, but it’s still a compromise.

Received on Wednesday, 28 May 2014 15:25:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC