RE: HTTP/2 response completed before its request

I see use cases for CANCEL in a couple of places:
  - Sender of a request no longer wants the response.  Cancel the request.
  - Recipient of a PUSH_PROMISE discovers it already has the resource in cache and doesn't want another copy.  Cancel the push.
  - Sender of a PUSH_PROMISE discovers it no longer has the resource it intended to push.  Cancel the push.

(Or maybe they *are* all senders, and push blurs the line about who's the sender....)

-----Original Message-----
From: Jason Greene [mailto:jason.greene@redhat.com] 
Sent: Wednesday, July 2, 2014 10:15 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

Ok that makes sense. From my perspective, CANCEL felt like it only makes sense for senders, and that sounds like what you are saying. Although, I guess in practice it doesn¡¯t really matter it only affects error logs and such.

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

> 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
> 

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

Received on Wednesday, 2 July 2014 17:22:07 UTC