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

Roy,

I think the issue *I* have with more 1xx status codes is that, thanks to the precedent set by 101, the recipient can't just ignore a 1xx status code it doesn't understand and wait for another response to come along.  And there is no guarantee that a particular status code is transmitted end-to-end - 101 is certainly a per-hop mechanism, and in my experience 100 is commonly dropped by proxies.


On Jul 18, 2014, at 1:19 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> 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/
>> 
>> 
>> 
>> 
>> 
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair