RE: HTTP/2 response completed before its request

I believe that was part of the original question, however many hundred e-mails ago.  :-)

Either seems applicable (no longer needed, nothing wrong), but I'm leaning toward NO_ERROR when coming from the client, since the request did complete successfully.  CANCEL suggests to me that the response is no longer interesting.

-----Original Message-----
From: Jason Greene [mailto:jason.greene@redhat.com] 
Sent: Wednesday, July 2, 2014 9:26 AM
To: Mike Bishop
Cc: Willy Tarreau; "William Chan (³ÂÖDzı)"; Martin Thomson; Patrick McManus; Jeff Pinner; Jesse Wilson; HTTP Working Group
Subject: Re: HTTP/2 response completed before its request


On Jul 2, 2014, at 10:43 AM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

> Kind of.  In HTTP/1.1, if you¡¯ve started receiving entity body and decide you don¡¯t want it any more, you have to RST the TCP connection.  That doesn¡¯t mean you keep reading to the end, but it does mean that until the server sees the RST, they¡¯re going to keep sending data your way and it gets dropped either by your TCP stack or some intermediary who¡¯s tracking TCP session state.
> 
> In HTTP/2, you can do the same thing, RST the stream.  But the scenario here is when the request is completed, not because the client doesn¡¯t need the response any more, but because the server already sent the response and doesn¡¯t need the request body.
> 
> I think it¡¯s entirely appropriate for the client to RST_STREAM NO_ERROR in this situation, to alert the server that it¡¯s abruptly stopping the (unneeded) entity body.  The concern is that complementary bugs could interact in the wild:
> 	? Client doesn¡¯t read HEADERS/DATA until it has finished sending the body
> 	? Server doesn¡¯t send WINDOW_UPDATE on a half-closed stream

Is it RST_STREAM CANCEL or NO_ERROR? 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

Received on Wednesday, 2 July 2014 16:34:12 UTC