Re: HTTP/2 response completed before its request

It think we need to stop conflating application state with the stream
state.   The state diagram (despite it's limitations) in the spec says it
all - a stream is close when both directions have sent/received end
stream.   There is no requirement for one direction to end_stream before
the other.

This is exactly the same in HTTP/1 with TCP/IP half closed connections.
There is no requirement at all on a TCP/IP connection for data in one
direction to shutdown before data in the other direction, so good HTTP
implementation have to just deal with that complexity.  This allows HTTP
responses to be sent even with a FIN to terminate content, before the
request has been completely sent.

HTTP/2 should do the same... in fact I could argue that our charter
requires us to do so :)

cheers








On 2 July 2014 09:09, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 1 July 2014 20:41, Martin Thomson <martin.thomson@gmail.com> wrote:
>
>> The stall is half of the problem, but do you cancel the send as well?
>> If the server has provided a response and closed the stream, there is
>> no point in continuing to send them data.  Especially if they forget
>> to send window updates.
>>
>
> I don't agree.  It is certainly possible to write server application code
> that commits a response and then processes the request data.     It's not a
> very good way of doing it and probably invites all sorts of application
> races.... but i don't think the transport layer can conclude that it is
> necessarily a bad thing.
>
>
> 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.