Re: 103 (Early Hints) vs. response headers

[Kazuho Oku <[e-mail]>]

Hi Willy,

Thank you for your response. My responses in-line.

2017-03-15 15:22 GMT+09:00 Willy Tarreau <[e-mail]>:
> On Wed, Mar 15, 2017 at 12:02:53PM +0900, Kazuho Oku wrote:
>> 2017-02-24 9:12 GMT+09:00 Mark Nottingham <[e-mail]>:
>> > My .02 -
>> >
>> >> On 24 Feb 2017, at 2:27 am, Vasiliy Faronov <[e-mail]> wrote:
>> >>
>> >>    HTTP/1.1 103 Early Hints
>> >>    Link: </another-resource>; rel=preload
>> >>    Warning: 299 - "something is not quite right"
>> >>
>> >>    HTTP/1.1 200 OK
>> >>    Date: Thu, 23 Feb 2017 16:49:43 GMT
>> >>    Content-Type: text/html
>> >>    Link: </another-resource>; rel=preload
>> >>    Connection: close
>> >>
>> >>    ...text goes here...
>> >>
>> >> Should it log/display the warning (as applied to the 103 response), or
>> >> discard it (as missing from the 200 response)?
>> >>
>> >> Should the spec for 103 be more explicit about this?
>> >
>> > My reading is that "officially", the Warning is not in the response; the server thought something was wrong early in the process, but then realised it was fine.
>> >
>> > So, it MAY log/display the warning, but if it doesn't, it's still conformant.
>> >
>> > Some more examples might help.
>>
>> RFC 6265 states that a user agent "MAY ignore Set-Cookie headers
>> contained in responses with 100-level status codes".
>
> Yes but it's mostly as a warning for server side to know that any cookie
> sent there may be ignored (since 1xx may be appear multiple times and be
> silently skipped).

Agreed.

>> 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).

> Cheers,
> Willy



-- 
Kazuho Oku