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

Hi Julian,

Thank you very much for your comments.

I will create a PR fixing the editorial issues. For the other issues,
my responses in-line.

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
...
```

>    ...
>
>    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.

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

>    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.

>
> 3.  Security Considerations
>
>    Some clients might have issues handling 103 (Early Hints), since
>    informational responses are rarely used in reply to requests not
>    including an Expect header ([RFC7231], Section 5.1.1).
>
> s/header/header field/
>
>    In particular, an HTTP/1.1 client that mishandles an informational
>    response as a final response is likely to consider all responses to
>    the succeeding requests sent over the same connection to be part of
>    the final response.  Such behavior may constitute a cross-origin
>
> s/may/might/ or /can/ (or invoke https://tools.ietf.org/html/rfc8174)
>
>    information disclosure vulnerability in case the client multiplexes
>    requests to different origins onto a single persistent connection.
>
>    ...
>
> 5.  Acknowledgements
>
> Nit: This should be an appendix (the last one).
>
> 6.  Changes
>
> Nit: This should be an appendix.
>
>
> Best regards, Julian



-- 
Kazuho Oku

Received on Monday, 26 June 2017 02:39:56 UTC