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

My opinion hasn't changed.

If we don't support 100 then we can't ask the endpoint (not just the
next hop) to verify that it will process the data in a large upload before
sending that large upload.  I don't care if browsers don't use this feature.
It is commonly used in authoring environments for customers with large
data nodes (GIS and DAM).  h2 framing can only do the same if there are
no intermediaries.

If we don't support 101 then I can't upgrade from h2 to waka within h2,
which means we are dropping existing HTTP functionality (for no apparent
reason other than WG-arrogance that h2 is an end-protocol).  Upgrade
does work.  Reports that it does not are nothing more than repeated
myths based on old code that has no relevance to h2.

If we don't support 102 then we don't have a means of indicating
long-running status to the client without signaling a 203.  Note that
this code was requested before WebDAV, but was defined by them because
RFC2068 had already been published.  Swallowing the response
doesn't seem to support the server's intent.  And, yes, the code is
used in practice, most commonly with encapsulated legacy systems; e.g.,

  http://stackoverflow.com/questions/16890668/how-to-deal-with-102-response-in-lwpuseragent

If we don't support 1xx, in general, then h2 is less extensible than HTTP/1,
again for no apparent reason other than WG-arrogance that we'll get it right
the first time.

All of these codes have been implemented in practice.  I have used
them, interoperably, in both non-browser user agents and origin servers.
I would have used them in javascript as well if they were passed through
to the script consistently.

AFAICT, this working group is short on experience and too focused on
browser usage of HTTP.  Get over it.  Each of these codes have a purpose
and it does no harm to support that purpose even if you don't personally
need it. Don't remove features just because you haven't used them.
If you want to do that, feel free to do so in a protocol called SPDY.

The only reason we don't have more 1xx codes is because I haven't seen
a need for any more, and neither has anyone else.  How could that possibly
be seen as a negative for 1xx?  I also didn't see a need for any of the
other status codes defined since RFC2068, until someone showed that there
was a need. None of us are omniscient, which is why we have extensibility.
If you want a protocol to last a few decades, don't assume too much.

....Roy

On Jul 16, 2014, at 10:40 PM, Mark Nottingham wrote:

> <https://github.com/http2/http2-spec/issues/535>
> 
> So far, we've had two proposals for this issue;
> 
> a) Accommodating non-final responses in HTTP/2
>    See Julian's proposal at <https://gist.github.com/reschke/48ec30b0ac9d012b8b4e> 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: <http://tools.ietf.org/html/rfc4918#appendix-F.3>)
> 
> 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   https://www.mnot.net/
> 
> 
> 
> 
>

Received on Friday, 18 July 2014 17:19:36 UTC