- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 2 Jul 2014 19:06:59 +0200
- To: Patrick McManus <mcmanus@ducksong.com>
- Cc: "William Chan (?????????)" <willchan@chromium.org>, 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 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. Thanks Willy
Received on Wednesday, 2 July 2014 17:07:49 UTC