- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 1 Nov 2016 07:32:01 +0100
- To: Kazuho Oku <kazuhooku@gmail.com>, Cory Benfield <cory@lukasa.co.uk>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 2016-11-01 02:32, Kazuho Oku wrote: > Cory, Julian, thank you for looking into the I-D. > > Thank you for looking into the existing implementations using Python. > Your research makes it evident that some kind of negotiation is > mandatory if we are going to use 103 on the public Internet. Having to negotiate it makes me sad. > For the purpose, defining an Accept-EH header (much like Accept-CH) > might make sense. For example, a client can send `Accept-EH: Link` to > indicate that it will recognize link headers within the Early Hints. Can't we use "Prefer"? > For HTTP/2, my tendency leans toward using HTTP headers rather than > having its own way of negotiation, considering the fact that the > information transferred using Early Hints could be considered > end-to-end rather than hop-by-hop, and also that we can expect HPACK > to compress Accept-EH header efficiently. For HTTP/2, I think we should push stronger to fix the code and not negotiate at all. >> >> I’ll start filing bugs against relevant repositories to address this behaviour so that the Python ecosystem is less embarrassingly unprepared for further 1XX status codes, but in the short-to-medium term it would be much better if we could negotiate the 103 status code rather than assume it will function correctly. > > Fantastic! Thank you for all your efforts. Best regards, Julian
Received on Tuesday, 1 November 2016 06:32:38 UTC