Re: Getting to Consensus on 1xx Status Codes (#535)

So at least it looks like all the voices here can live with 100 semantics.

For my own part, I see merit in both proposal: 1) implement exactly as in
rfc723x   vs 2) new mechanism designed to support 100 only, but not 1xx

>From an implementation point of view,  I probably prefer the former as it
keeps better separation of the layers, in that sending a 1xx carrying
header is a decision made above the framing layer.

The second is kind of possible to implement, but is not exactly the same
semantic and will blur the boundaries and complicate the flow control
algorithm.  On receiving a header with the proposed flag, the reverse flow
control window will need to be set to 0.   This is now different from 100
semantic, as h1 allows the body to be sent immediately or after a timeout,
where this prevents it being sent.    We will then need the request to be
dispatched for handling and some how communicate all the way down the the
flow control layer when it is possible to increase the window.    I'm not
that keen on tunnelling semantic all the way from the application layer
down to the flow control algorithm.

My server currently has all the logic to say "send a 100 message and keep
the request state open".  That is really easy to adapt to sending a headers
frame with 100 in it.    It can of course be plumbed into the flow control
algorithm, but it will not be as simple or clear.

So I guess in the end, I prefer keeping RFC723x semantic exactly.

cheers







-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.