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). Just my two cents, Willy