Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

[Kazuho Oku <[e-mail]>]

2016-11-14 18:14 GMT+09:00 Cory Benfield <[e-mail]>:
>
>> On 13 Nov 2016, at 16:40, Kari Hurtta <[e-mail]> wrote:
>>
>> It is also possible to Connection: -header implementation is broken.
>>
>> So if 1xx is broken, it does not help use Connection: for to
>> indicate hop-by-hop header if this is not honored either.
>>
>> Seems likely that both little used featured are broken
>> on same implementation.
>
> I suspect Kari and Kazuho are right here: it is likely that any implementation that mishandles 1XX responses will also mishandle the Connection header. My experience of working with implementations and implementers is that the Connection field is extremely poorly understood.
>
> This is unfortunate. I was advocating for the header-based negotiation because I believed that the state of affairs for intermediaries was likely to be better than it is for the long-tail of OSS client implementations, but it looks like it isn’t. With that in mind then, I think we have three options:
>
> 1. As Julian suggested, restrict use of this response to HTTPS only and then negotiate via header field. This doesn’t necessarily solve the problem (HTTPS may be used to an intermediary), and also preferences the needs of clients over intermediaries. I’m not sure that’s a good plan.
>
> 2. As Kazuho has suggested, restrict use of the status code to H2 where implementations generally-speaking handle the less-used spec features better.
>
> 3. Don’t put any spec limitations on the use of the status code and allow implementers to decide under what conditions they are willing to emit the header field.
>
>
> For my part, I think either 2 or 3 is the best solution. I don’t see any reason to want to do an end-run around intermediaries like in (1). I’m open to (3). I think in practice we will see limited update in HTTP/1.1 for a while, but that may have to just be ok.

Thank you for laying down the options.

My preference is 3, with possibly some warnings using non-normative
form alerting the reader that there might be interoperability issues
especially when HTTP/1 is used.

> Cory



-- 
Kazuho Oku