W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

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>
Message-ID: <5f155947-e74c-0761-b5d4-64f8aabec846@gmx.de>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 November 2016 06:32:51 UTC