Re: Last Call: <draft-ietf-httpbis-early-hints-03.txt> (An HTTP Status Code for Indicating Hints) to Experimental RFC

[Mark Nottingham <[e-mail]>]

> On 26 Jun 2017, at 12:39 pm, Kazuho Oku <[e-mail]> wrote:

> The reasons I added a clause prohibiting the use of hop-by-hop headers
> in an 103 response are as follows:
> * does not make sense for a response that attempts to send the
> metadata of a final response early
> * to avoid confusion caused by sending a hop-by-hop header in the 103 response
> 
> Without the restriction, a response like below would be valid, which
> IMO is confusing at least.
> 
> ```
> HTTP/1.1 103 Early Hints
> Connection: close
> Link: </style.css>; rel=preload
> 
> HTTP/1.1 200 OK
> Connection: close
> Link: </style.css>; rel=preload
> ...
> ```

Perhaps you could just give guidance that only the headers intended as early hints should be sent?


> The statement exists since sending 103 only makes sense when it is
> impossible to immediately send a final response.
> 
> For example, there is no need for a cache that is in possession of a
> freshly-cached final response to send a 103 that was sent from the
> origin before sending the final response. I also believe that most
> caching proxies that exist today do not cache informational responses,
> and that there is no need for us to require them to do so.
> 
> Considering the facts, one way to resolve the issue would be to adjust
> the statement to something like "An intermediary MAY omit the 103
> response when resending a cached response", and argue that re-sending
> a cached response is not an action of "forwarding," which is defined
> as a MUST in RFC 7231.
> 
> But wouldn't it be simpler to just have the "MAY drop" clause for any
> intermediary?

Re-specifying HTTP for a special case isn't a good idea. I think you could mention that gateways can decide not to forward a 103 response at their discretion / depending on their configuration, but I don't know if I'd put a requirement around it. Also, see below.

As an aside -- HTTP only specifies very general requirements for gateways; by their nature, they're black boxes (the back-end protocol *can* be HTTP, but it doesn't have to be, and how they connect the two sides in that case is also unspecified). So I wouldn't go into too much detail about their operation.


> Yes. They need to, especially if caching is involved. 103 is an
> intermediary response and there is no guarantee (or a requirement) for
> a cache to retain the headers included only in the informational
> response.
> 
> In case of link rel=preload headers, a client can speculatively load
> the resources included in the headers while revalidating a
> stale-cached response, or a caching proxy can generate a 103 response
> from a stale-cached 200 response, while waiting for the origin to
> perform revalidation.

The underlying problem here is that the caching model doesn't talk about final and non-final responses. 

I've raised <https://github.com/httpwg/http11bis/issues/29>. I don't think that you need to specify anything about this.


--
Mark Nottingham   https://www.mnot.net/