ietf
[Top] [All Lists]

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

2017-06-26 22:52:30
Hi Mark, Julian,

Thank you for your comments / suggestions.

I have created a pull request that hopefully would address the issues
being raised: https://github.com/httpwg/http-extensions/pull/363;
please let me know what you think.

The PR removes the statements that have been pointed out either as
redundant or in contradiction with RFC 723x. It also gives guidance to
servers how they should generate the 103 headers.

Regarding the action of an intermediary, I like the Mark's view
(stated in the new GitHub issue) that caches are expected to store
only final responses and that it should be clarified in the next
revision of HTTP. Considering that way, I think we do not need to
specify how a intermediary needs to deal with a 103 response (except
for the fact that a HTTP/2 gateway might create a HTTP/2 push based on
the information found in the informational response).

2017-06-27 10:05 GMT+09:00 Mark Nottingham <mnot(_at_)mnot(_dot_)net>:

On 26 Jun 2017, at 12:39 pm, Kazuho Oku <kazuhooku(_at_)gmail(_dot_)com> 
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/




-- 
Kazuho Oku


<Prev in Thread] Current Thread [Next in Thread>