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

HTTP/2 REFUSED_STREAM and applications

From: Robert Collins <robertc@robertcollins.net>
Date: Mon, 29 Sep 2014 15:52:47 +1300
Message-ID: <CAJ3HoZ1XTqRdqgxLAxgrUdFWktO2-e1XsdQOVBt6=r4=eVKG_A@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
We've got this prose in the draft: "A server MUST NOT indicate that a
stream has not been processed unless it can guarantee that fact. If
frames that are on a stream are passed to the application layer for
any stream, then REFUSED_STREAM MUST NOT be used for that stream, and
a GOAWAY frame MUST include a stream identifier that is greater than
or equal to the given stream identifier."

I find the bit "If frames that are on a stream are passed to the
application layer for any stream, then REFUSED_STREAM MUST NOT be used
for that stream" more than a little odd: an application may well
cooperate in the HTTP/2 semantics and be able to guarantee 'this has
not been processed' (e.g. as an example of that, if a SQL conflict is
detected and the transaction rolls back - absolutely nothing has been
done). Prohibiting application authors from exposing this seems like a
poor idea - I presume its to prevent *existing* application gateway
APIs that don't offer the same granularity from leading to
inconsistencies. Right now though, I'm looking at what to do to
Python's WSGI to support HTTP/2 well, and being able to issue
REFUSED_STREAM would allow exposing more of the capabilities to 'app'
authors.

tl;dr - nothing is documented in the spec about why applications
cannot guarantee 'not processed' any more or less effectively than the
protocol engine itself.

-Rob

-- 
Robert Collins <rbtcollins@hp.com>
Distinguished Technologist
HP Converged Cloud
Received on Monday, 29 September 2014 02:53:15 UTC

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