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

[Kazuho Oku <[e-mail]>]

2016-11-01 15:32 GMT+09:00 Julian Reschke <[e-mail]>:
> 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