Re: 103 Early Hints

I am in favor of updating the RFC.

Agree on the advice to use it on HTTP/2 and up on the public internet.
>
> Against Accept-CH confusions. As Patrick says, middle boxes wont care. It
> will just end up in the toolbox of client fingerprinting.
>
>
I agree with this. I am not sure Accept-EH is useful.

Dragana


> Cheers,
> Stefan
>
>
>
> On Sat, Jun 10, 2023 at 3:13 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
> wrote:
>
>> Hi folks,
>>
>> RFC 8297, defining 103 Early Hints was published in 2017. It's been a bit
>> of a sleeper hit, in the last 18 months or so we've seen uptake and
>> deployment on client and server sides.
>>
>> As is natural, we've been gaining experience through deployment. Helping
>> to identify the areas with Early Hints helps, and areas where there might
>> be some possible tweaks. One example is that it isn't always useful to emit
>> a 103 Early Hint in response to every request that is received, because the
>> client's processing context would ignore it.
>>
>> Client Hints (RFC 8942) has some text that deals with considerations we
>> are now learning about Early Hints. For instance, a server could emit an
>> Accept-CH header, and Section 5 of RFC 8942 describes considerations for
>> the cost of sending Client Hints.
>>
>> After some chatter on Twitter the past week, a few different people
>> suggested that something like an Accept-EH request header field might be
>> useful to help clients to indicate when Early Hints are useful or not. If
>> we made this a list of field names, it could allow some tailoring of the
>> emission and content of the hints.
>>
>> My thinking was maybe its time to upgrade Early Hints from experimental
>> and roll in some of the learnings / proposals into the update document.
>>
>> Thoughts?
>>
>> Cheers,
>> Lucas
>>
>