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

Julian Reschke <julian.reschke@gmx.de> Mon, 26 June 2017 10:36 UTC

Subject: Re: Last Call: <draft-ietf-httpbis-early-hints-03.txt> (An HTTP Status Code for Indicating Hints) to Experimental RFC
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: ietf@ietf.org, httpbis-chairs@ietf.org, Mark Nottingham <mnot@mnot.net>, draft-ietf-httpbis-early-hints@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, alexey.melnikov@isode.com
References: <149806437201.15854.12299810594896460001.idtracker@ietfa.amsl.com> <dcdff226-e12d-bb83-982f-8253f46ae935@gmx.de> <CANatvzygaU9oiof3-5TqnWdxqXOGNyGqPvNhTnpPzYy391CzNw@mail.gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <632d93e7-eab5-dcbe-e971-64e3b27ddb4e@gmx.de>
Date: Mon, 26 Jun 2017 12:36:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CANatvzygaU9oiof3-5TqnWdxqXOGNyGqPvNhTnpPzYy391CzNw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/xAmb7UWPnvGiYiWTXiQvENCnrhE>
Precedence: list

On 2017-06-26 04:39, Kazuho Oku wrote:
> ...
> 2017-06-25 19:11 GMT+09:00 Julian Reschke <julian.reschke@gmx.de>:
>> On 2017-06-21 18:59, The IESG wrote:
>>>
>>>
>>> The IESG has received a request from the Hypertext Transfer Protocol WG
>>> (httpbis) to consider the following document: - 'An HTTP Status Code for
>>> Indicating Hints'
>>>     <draft-ietf-httpbis-early-hints-03.txt> as Experimental RFC
>>> ...
>>
>>
>>
>> Here's my feedback...:
>>
>> 2.  103 Early Hints
>>
>>     ...
>>
>>     A server MUST NOT include Content-Length, Transfer-Encoding, or any
>>     hop-by-hop header fields ([RFC7230], Section 6.1) in a 103 (Early
>>     Hints) response.
>>
>> That's a bit weird here, because the requirements for C-L and T-E are
>> generic to 1xx, and already are stated in RFC 7230. The text above makes it
>> sound as if these are specific to 103, which they are not.
>>
>> For hop-by-hop, I'm not convinced that the requirement is needed here.
> 
> I agree that we do not need to talk about C-L and T-E here.
> 
> 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
> ...
> ```

Yes, but does that mean we need a normative requirement? Also, is it 
really obvious that no future hop-by-hop header field could be 
meaningful on a 103?

>>     ...
>>
>>     An intermediary MAY drop the informational response. (...)
>>
>> That seems to contradict a MUST-level requirement in RFC 7231
>> (https://www.greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.2.p.3)
> 
> 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.

Sounds good to me.

> But wouldn't it be simpler to just have the "MAY drop" clause for any
> intermediary?

In that case, the spec would contradict RFC 7231, which is bad position 
to be in...

>>     The following example illustrates a typical message exchange that
>>     involves a 103 (Early Hints) response.
>>
>>     Client request:
>>
>>       GET / HTTP/1.1
>>       Host: example.com
>>
>> (maybe insert blank line do delimit the message)
>>
>>     Server response:
>>
>>       HTTP/1.1 103 Early Hints
>>       Link: </style.css>; rel=preload; as=style
>>       Link: </script.js>; rel=preload; as=script
>>
>>       HTTP/1.1 200 OK
>>       Date: Fri, 26 May 2017 10:02:11 GMT
>>       Content-Length: 1234
>>       Content-Type: text/html; charset=utf-8
>>       Link: </style.css>; rel=preload; as=style
>>       Link: </script.js>; rel=preload; as=script
>>
>>       <!doctype html>
>>       [... rest of the response body is ommitted from the example ...]
>>
>> The example suggests that early hints are repeated in the final response. Do
>> they have to, actually?
> 
> 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.

What I'm after is a clear statement whether they really need to be 
repeated, as normative language.

> ...

Best regards, Julian

Re: Last Call: <draft-ietf-httpbis-early-hints-03… Julian Reschke
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Willy Tarreau
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Julian Reschke
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Willy Tarreau
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Julian Reschke
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Willy Tarreau
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Kazuho Oku
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Julian Reschke
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Julian Reschke
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Alex Rousskov
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Mark Nottingham
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Kazuho Oku
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Willy Tarreau
RE: Last Call: <draft-ietf-httpbis-early-hints-03… Mike Bishop
Re: Last Call: <draft-ietf-httpbis-early-hints-03… Mark Nottingham