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

2017-07-07 18:23 GMT+09:00 Willy Tarreau <w@1wt.eu>:
> 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

Received on Friday, 7 July 2017 11:30:09 UTC