Subject: Re: 103 (Early Hints) vs. response headers

From: Kazuho Oku <[email-masked]>
Date: Wed, 15 Mar 2017 12:02:53 +0900

2017-02-24 9:12 GMT+09:00 Mark Nottingham <[email-masked]>:
> My .02 -
>
>> On 24 Feb 2017, at 2:27 am, Vasiliy Faronov <[email-masked]> 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".

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.

> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>

-- 
Kazuho Oku

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 15 Mar 2017 07:22:42 +0100

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

> response but not the informational response itself, then we'd be

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.

Cheers,
Willy

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 16 Mar 2017 22:55:31 +0900

Hi Willy,

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

> sent there may be ignored (since 1xx may be appear multiple times and be

Agreed.

> will make good use of it, not as a guarantee, so I don't think it

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

-- 
Kazuho Oku

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Mar 2017 15:31:58 +0100

Hi Kazuho,

> (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

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 17 Mar 2017 00:10:43 +0900

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.

-- 
Kazuho Oku

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 16 Mar 2017 17:05:43 +0100

> Am 16.03.2017 um 16:10 schrieb Kazuho Oku <[email-masked]>:
> 

+1

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Mar 2017 11:35:29 +1100

> On 17 Mar 2017, at 12:55 am, Kazuho Oku <[email-masked]> wrote:
> 

Just a note -- one of the possible outcomes is that we decide that's a bug in 6265. Do we have any data on clients with cookie jars that actually do this?

Cheers,

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 18 Mar 2017 21:48:33 +0900

> Just a note -- one of the possible outcomes is that we decide that's a bug in 6265. Do we have any data on clients with cookie jars that actually do this?

Thank you for the suggestion.

I'd prefer RFC 6265 defining the behavior for all of the 100-level
response be considered as a bug. I do not see why the definition needs
to be different from that of RFC 7231 section 6.2; quote: "A user
agent MAY ignore unexpected 1xx responses."

OTOH, please let me note that even if we consider that RFC 6265 should
be corrected to align with the definition found in RFC 7231, the
discussion of if we should recognize the headers of an 103 response as
belonging to the response itself remains.

-- 
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 29 Mar 2017 15:27:08 -0500

Hi!

> 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

-- 
Kazuho Oku

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 30 Mar 2017 10:08:53 +0200

> Am 29.03.2017 um 22:27 schrieb Kazuho Oku <[email-masked]>:
> 
> Hi!
> 

+1