Re: 103 (Early Hints) vs. response headers

[Kazuho Oku <[e-mail]>]

Thank you for pointing that out. It's good to know that there'd be
ways to detect the behavior of a client.

OTOH, I think that, in the long term, we would benefit more from
having a well-defined behavior than detecting and handling clients
that behave in various ways.

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.

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