Re: 103 (Early Hints) vs. response headers

[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