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

RE: HTTP/2 response completed before its request

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Wed, 2 Jul 2014 17:21:36 +0000
To: Jason Greene <jason.greene@redhat.com>
CC: Willy Tarreau <w@1wt.eu>, "William Chan (Dz)" <willchan@chromium.org>, Martin Thomson <martin.thomson@gmail.com>, "Patrick McManus" <mcmanus@ducksong.com>, Jeff Pinner <jpinner@twitter.com>, "Jesse Wilson" <jesse@swank.ca>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <7a3a39044ce442ca92dcb2fbc198e484@BL2PR03MB132.namprd03.prod.outlook.com>
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 doesnt 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 youve started receiving entity body and decide you dont want it any more, you have to RST the TCP connection.  That doesnt mean you keep reading to the end, but it does mean that until the server sees the RST, theyre going to keep sending data your way and it gets dropped either by your TCP stack or some intermediary whos 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 doesnt need the response any more, but because the server already sent the response and doesnt need the request body.
>> 
>> I think its entirely appropriate for the client to RST_STREAM NO_ERROR in this situation, to alert the server that its abruptly stopping the (unneeded) entity body.  The concern is that complementary bugs could interact in the wild:
>> 	? Client doesnt read HEADERS/DATA until it has finished sending the body
>> 	? Server doesnt 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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC