- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 7 Jul 2017 11:23:16 +0200
- To: Melinda Shore <melinda.shore@gmail.com>
- Cc: Kazuho Oku <kazuhooku@gmail.com>, secdir@ietf.org, draft-ietf-httpbis-early-hints.all@ietf.org, IETF Discussion Mailing List <ietf@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Friday, 7 July 2017 09:23:53 UTC