Re: 103 (Early Hints) vs. response headers

[Stefan Eissing <[e-mail]>]

> Am 29.03.2017 um 22:27 schrieb Kazuho Oku <[e-mail]>:
> 
> Hi!
> 
> 2017-03-16 10:10 GMT-05:00 Kazuho Oku <[e-mail]>:
>> Therefore, my preference goes to explicitly stating that the headers
>> of a 103 response must not be applied as part of the informational
>> response, and if there's a need in practice to make such distinction,
>> introduce negotiation to Early Hints.
> 
> I have uploaded -01[1]. The only change from -00 is that it now
> explicitly forbids processing the headers of an 103 response as part
> of the informational response.
> 
> I believe that we have not reached a consensus, but I hope that having
> the draft standing on one side would accelerate the debate.

+1

> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-httpbis-early-hints/?include_text=1
> 
>> 2017-03-16 23:31 GMT+09:00 Willy Tarreau <[e-mail]>:
>>> Hi Kazuho,
>>> 
>>> On Thu, Mar 16, 2017 at 10:55:31PM +0900, Kazuho Oku wrote:
>>>>>> So to me it seems that if we state in Early Hints that the headers of
>>>>>> a 103 response is ones that are applied (speculatively) to the final
>>>>>> response but not the informational response itself, then we'd be
>>>>>> overriding RFC 6265.
>>>>> 
>>>>> I'm not seeing it this way. In fact you may decide to put some headers
>>>>> there for this exact reason : while 1xx MAY be ignored, those implementing
>>>>> 103 MAY/WILL consider them. And you're sending 103 hoping that someone
>>>>> will make good use of it, not as a guarantee, so I don't think it
>>>>> contradicts 6265.
>>>> 
>>>> While I would not say that RFC 6265 and Early Hints would contradict,
>>>> I still think that the requirement of how a Set-Cookie header _can_ be
>>>> handled is narrowed by Early Hints. Consider the response below.
>>>> 
>>>> HTTP/1.1 103 Early Hints
>>>> Set-Cookie: a=b
>>>> 
>>>> HTTP/1.1 200 OK
>>>> Content-Type: text/plain; charset=utf-8
>>>> Content-Length: 12
>>>> 
>>>> Hello world
>>>> 
>>>> RFC 6265 allows the client to store cookie `a` by stating that a
>>>> client MAY accept a Set-Cookie header within any 100-level response.
>>>> 
>>>> If we are to state in Early Hints that the headers of a 103 response
>>>> are to be applied (speculatively) to the final response but not to the
>>>> informational response itself, we would effectively be forbidding such
>>>> behavior for clients that implements 103.
>>>> 
>>>> In other words, a client that _do_ recognize a Set-Cookie header in
>>>> 100-level responses (it is a MAY in RFC 7230 section 6.2) would need
>>>> to special-case the handling of 103. From server-side perspective, it
>>>> would continue to be unable to expect whether if the client would
>>>> accept or ignore the set-cookie header in a 103 response since there
>>>> is no negotiation for Early Hints.
>>>> 
>>>> To me this seems like a variation of what was pointed out by Vasiliy
>>>> (by using the Warnings header).
>>> 
>>> Hmmm I see, indeed you can end up in an unknown state there. But maybe
>>> once properly documented it can be turned to a benefit for improved
>>> deployment. Let's consider this for example :
>>> 
>>> HTTP/1.1 103 Early Hints
>>> Set-Cookie: cookie_support_on_103=yes
>>> 
>>> HTTP/1.1 200 OK
>>> Content-Type: text/plain; charset=utf-8
>>> Set-Cookie: this_is_a_regular=application_cookie
>>> Content-Length: 12
>>> 
>>> Hello world
>>> 
>>> The server can detect in a subsequent request whether or not the path is
>>> clean. And by registering a standard cookie name for this use case we
>>> could even end up with the first request sending the information regarding
>>> this support from the browser based on the learning from a previous call
>>> without ever conflicting with application cookies, meaning that on subsequent
>>> calls the server may decide to pass much more info on the 103 response. Of
>>> course the cookie name and value would have to be much shorter than in the
>>> example above :-)
>>> 
>>> Willy
>> 
>> 
>> 
>> --
>> Kazuho Oku
> 
> 
> 
> -- 
> Kazuho Oku
>