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: Kazuho Oku <kazuhooku@gmail.com>
Date: Tue, 1 Nov 2016 16:08:43 +0900
Message-ID: <CANatvzwNDHd0bhDSWBZ2DxezxxrLwLFjZ7PsyCMthy64_xh4Bg@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Cory Benfield <cory@lukasa.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
2016-11-01 15:32 GMT+09:00 Julian Reschke <julian.reschke@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.

Thank you for the suggestion.

I think having negotiation is a good thing for Early Data, since there
is no point in sending Early Data to a client that does not recognizes
the headers included in the informational response. So I'd expect that
if we define an Accept-EH header, a server serving to the Internet
will send Early Data only when the header has included in the request.

OTOH, we do not need to use Accept-EH header on a deployment in which
the peer is known to support Early Data.

Considering the two, having a clause like the following (with
non-normative text explaining the background) seems reasonable to me:

    “a server SHOULD NOT send Early Data unless the client has sent an
Accept-EH header”

Does this look fine to you?

>> 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

Kazuho Oku
Received on Tuesday, 1 November 2016 07:09:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 November 2016 07:09:21 UTC