- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 26 Jun 2017 12:36:36 +0200
- 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
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
Received on Monday, 26 June 2017 10:37:21 UTC