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

My preference is for 100 support.  Julian'd draft looks ok except that it
excludes support for 100.   I'm fine with it excluding support for 101 and

If 100 had been deprecated in rfc723x, then I'd would have lived with
dropping it better, as I could have just dropped it entirely from the
server and referred broken applications to the RFC.   But it is not
deprecated for current h1 usage, so end points that will support both h1/h2
will need to have 100 continue support anyway.  Making it dependent on the
transport probably increases the complexity rather than decreases it.

So I could live with b) if that document is targeted to both h1 and h2, so
there is some prospect that we can drop support entirely in a few


On 17 July 2014 15:40, Mark Nottingham <> wrote:

> <>
> So far, we've had two proposals for this issue;
> a) Accommodating non-final responses in HTTP/2
>     See Julian's proposal at <
>> for an idea of how
> this would look in the spec.
> b) Publishing a separate document deprecating 1xx status codes
>     Thereby preventing the establishment of new ones (HTTP/2 already
> defines how to deal with 100, and 101 is not relevant to this protocol. 102
> was dropped by its primary use case, WebDAV, here: <
> I'd like to hear:
> 1) Your preferred outcome (if any)
> 2) Whether you can live with the other option, and if not, why
> "I have no preference" is useful information too.
> If you indicate you can't live with one (or both) of the options, you MUST
> give a detailed, relevant reason as to why; omitting the reason means your
> "can't live with" will be ignored.
> Thanks,
> --
> Mark Nottingham

Greg Wilkins <> HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

Received on Thursday, 17 July 2014 06:29:29 UTC