Re: HEADERS and flow control

Actually, it is even worse than what I just described.

If the resource constrained server does not have the resources to accept
the 250B extra header, it can RST_STREAM, but it still has to process the
headers, because of the shared state table.   So if the server really is
resource constrained, and wants to limit the resources of each connection,
then it wont just RST_STREAM, it will GO_AWAY the whole connection - and
all the work in progress on all the other streams will be lost!

Unless the server is able to exert back pressure on the client to stop it
sending more data than the server is prepared to handle, then the only
viable response the server has is to close the connection.   Saying that
there is no flow control on headers only works if you are talking to a
fantasy infinite server!

Any server that is lenient and allows clients to go significantly beyond
resource limits, just because the data is in a headers frame rather than a
data frame, is just going to be exploited!

regards










On 28 May 2014 18:16, Greg Wilkins <gregw@intalio.com> wrote:

>
>
>
> On 28 May 2014 17:16, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
>
>>
>> On Wed, May 28, 2014 at 11:55 PM, Greg Wilkins <gregw@intalio.com> wrote:
>>
>>>
>>> Tatsuhiro,
>>>
>>> but flow control exists to limit the resources that a server must
>>> dedicate to a connection.  If the window is 0, then the server is saying
>>> that it does not have any more resources available.   So the client simple
>>> should not send a new stream as there are no server resources.
>>>
>>>
>> Are you saying that while server retains request headers in memory, it
>> must not respond WINDOW_UPDATE since it is the commitment of the resource?
>>  If so, the connection window gets drastically small and concurrency is
>> vastly reduced.
>>
>
> No I'm not saying that.  I'm saying that with flow control the server
> makes a fixed memory commitment when it accepts a connection.   If it is
> prepared to accept more data it will send a WINDOW_UPDATE.
>
> If the server is not prepared to accept any more data from a connection,
> then it will not send a WINDOW_UPDATE.  If the client then sends enough
> data to consume the window, then the window is consumed and the client
> should be flow controlled.
>
> So just saying, that the data the client wants to send is meta-data in a
> header field does not some how make the server have any more resources
> available in order to handle those HEADER/CONTINUATION frames.  Sending
> additional headers when the flow control windows are full violates the
> resource contract between client and server as the client is asking the
> server to handle and store an unlimited amount of extra data.
>
> I well written server will reset the stream, a not so well written server
> may try to continue but may eventually throw an out of memory exception and
> crash.   Eitherway, the non-flow controlled header data does not get
> through and the dead lock is not resolved (well I guess crashing the server
> will resolve the dead lock).
>
>
>  By removing the protection of excess resource consumption from the
>>> protocol will not magically give the server any more resources.
>>>
>>> In the case that you give, if there are 200 bytes available, but the
>>> headers of a new stream is 250, then there can be two possibilities - the
>>> client sends the 250 without flow control and the server resets the stream
>>> because it has not resources  OR the client does not send the 250, but
>>> instead uses the 200 to allow another request to progress (and maybe
>>> complete).
>>>
>>>
>>
> In your example, you said that if we flow controlled headers then a client
> with a 250B header but only 200B window would not be able to send the
> header.     You said this as an argument to say the client should be able
> to send the 250B without flow control, otherwise an important request might
> not get through and you may get deadlock.
>
> I'm saying that a well written server that enforces resource limitations
> on connections would probably  reset the stream if you did send those 250B
> as it goes above the resource allocation it is prepared to make per
> connection.  Perhaps an accepting server might accept some additional
> requests even when they are low on resources, but servers are not infinite
> and at some point they will have to reject some incremental important 250B
> header set from the client (or crash) - so dead lock will result anyway.
>
> Removing flow control from headers has not avoided deadlock, it has just
> made the client unaware of the amount of data that it can send before
> deadlock will occur.
>
> regards
>
>
>
>
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
>



-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.