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

[Kazuho Oku <[e-mail]>]

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 <[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/
>



-- 
Kazuho Oku