On 2017-06-26 04:39, Kazuho Oku wrote:
...
2017-06-25 19:11 GMT+09:00 Julian Reschke
<julian(_dot_)reschke(_at_)gmx(_dot_)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