HTTP/2 REFUSED_STREAM and applications

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