- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Mon, 14 Nov 2016 14:56:44 +0900
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>
2016-11-14 13:48 GMT+09:00 Julian Reschke <julian.reschke@gmx.de>: > On 2016-11-13 13:36, Kazuho Oku wrote: >> >> ... >> I do not have a strong preference on whether if we should try to >> rescue the broken implementations, but to me your report is >> interesting in the fact that it shows the bounds of using header-based >> negotiation to work-around such implementations. >> >> HTTP headers are end-to-end by default. Therefore a request header for >> negotiating the use of 103 would go through an intermediary incapable >> of handling 1xx correctly. We might consider designating the header >> used for negotiation as a hop-by-hop header, but I'd be scared of >> using a new token to the connection header (for interoperability >> issues). >> >> In other words, using header-based negotiation for Early Hints only >> limitedly improves interoperability. >> ... > > > ...but then, requiring HTTPS (in theory eliminating broken middle boxes) > would, right? Yes. However, I would expect that in many (if not most) cases a web application server running behind of a reverse proxy (or a CDN edge server) to generate 103 response. In such deployment, TLS gets terminated by the reverse proxy. So even if a client and an application server negotiated the use of 103, we would see issues if the reverse proxy between the two was broken. So to me, it seems like that the conservative approach would be to only send 103 over HTTP/2 or to a peer that is known to handle it correctly (e.g. CDN edge server converting 103 LRP to H2 push). > Best regards, Julian -- Kazuho Oku
Received on Monday, 14 November 2016 05:57:18 UTC