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

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.


    An intermediary MAY drop the informational response. (...)

That seems to contradict a MUST-level requirement in RFC 7231 

    The following example illustrates a typical message exchange that
    involves a 103 (Early Hints) response.

    Client request:

      GET / HTTP/1.1

(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?

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

    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

Received on Sunday, 25 June 2017 10:12:17 UTC