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
(https://www.greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.2.p.3)
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?
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