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

Re: HTTP/2 response completed before its request

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Wed, 2 Jul 2014 10:11:00 -0700
Message-ID: <CAA4WUYhVAkEX9+EW0nGcWRYchNYeOUc0q5pb-VbfsOrWX6YszA@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Patrick McManus <mcmanus@ducksong.com>, Martin Thomson <martin.thomson@gmail.com>, Jeff Pinner <jpinner@twitter.com>, Jesse Wilson <jesse@swank.ca>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Jul 2, 2014 at 10:06 AM, Willy Tarreau <w@1wt.eu> wrote:

> On Wed, Jul 02, 2014 at 12:31:24PM -0400, Patrick McManus wrote:
> > On Wed, Jul 2, 2014 at 12:04 PM, Willy Tarreau <w@1wt.eu> wrote:
> >
> > > OK thanks for explaining. But I still fail to see the difference. And
> > > upload
> > > and a download are exactly the same, in both cases we're sending a
> message
> > > body and any party should be free to abort receipt saying it doesn't
> want
> > > it
> > > anymore.
> > >
> >
> > I agree - you just used the canceled download as an example - so I stayed
> > on track with it as it would be much more common that the scenario in
> this
> > thread.
> >
> > In the okhttp case the server is the one receiving a stream it might not
> > want. Its state is half-closed-local (because it has already generated
> the
> > END_STREAM) and from that state it can send a RST_STREAM, NO_ERROR and
> the
> > client ought to stop uploading stuff when it receives that.
>
> OK so it's more of an implementation issue than a protocol design issue ?
> Then maybe the case should be documented while it's hot so that nobody gets
> trapped again.
>

Yes, it's an implementation issue. Maybe add a new bullet to the
implementation advice wiki (https://github.com/http2/http2-spec/wiki/Advice
)?


>
> Thanks
> Willy
>
>
Received on Wednesday, 2 July 2014 17:11:28 UTC

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