Re: [secdir] Secdir last call review of draft-ietf-httpbis-early-hints-03

[Stefan Eissing <[e-mail]>]

I am not a big fan of "MUST not use protocol features if it is known not to work" advise.

> Am 07.07.2017 um 13:29 schrieb Kazuho Oku <[e-mail]>:
> 
> 2017-07-07 18:23 GMT+09:00 Willy Tarreau <[e-mail]>:
>> On Fri, Jul 07, 2017 at 05:54:41AM +0000, Melinda Shore wrote:
>>> On 7/6/17 8:40 PM, Kazuho Oku wrote:
>>>> Regarding the wording, I think it would be better to keep the tone
>>>> as-is, rather than suggesting implementers not to send an Early Hints
>>>> response over HTTP/1.1 depending on the client.
>>> 
>>> Yeah, you don't want to discourage implementation.  I think
>>> the goal is to find some balance between not putting off
>>> implementers on the one hand, and having to deal with an
>>> embarrassing incident on the other.  I'd be more comfortable
>>> with language that's a bit stronger but it's not a huge
>>> issue, certainly not one that's an impediment to moving the
>>> document forward (particularly given that it's intended for
>>> publication as an experimental standard).
>> 
>> I'm just thinking about the fact that we're not even sure that any
>> HTTP/1.1 client doesn't support these informational responses,
>> because such clients can already make use of Expect: 100-continue
>> (so they know about 100), and if I remember well when designing the
>> 101 upgrade for WebSocket, which was reused for HTTP/2, some of
>> the difficulties we faced was that some clients/intermediaries
>> were consuming 101 as 1xx and waiting for a final response after
>> it.
>> 
>> Maybe the stronger wording should be oriented differently, such as
>> "Servers MUST not send 103 to HTTP/1.0 clients nor to any client
>> known not to support 1xx informational responses" ? This way it
>> leaves the possibility opened (ie rely on version and/or user-agent
>> or anything else once an exception is known).
> 
> Considering that this is merely an advice on how to deal with broken
> clients, I think that we should not use the verbs defined in RFC 2119
> or state a strong prohibition.
> 
> I also believe that a whitelist-based approach will be a better choice
> than a blacklist-based one, since 103 is an optimization that is
> beneficial when sent to a client that is known to make use of it. For
> most websites, whitelisting the major browsers that support it (once
> they do) or the CDN they use will be enough to get the most out of the
> status code.
> 
>> Just my two cents,
>> Willy
> 
> 
> 
> -- 
> Kazuho Oku
>