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 <kazuhooku@xxxxxxxxx>: > > 2017-07-07 18:23 GMT+09:00 Willy Tarreau <w@xxxxxx>: >> 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 >