ietf
[Top] [All Lists]

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

2017-07-07 06:29:57
2017-07-07 18:23 GMT+09:00 Willy Tarreau <w(_at_)1wt(_dot_)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