Re: 103 (Early Hints) vs. response headers

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