- From: Felix Hassert <felix@ferndrang.de>
- Date: Tue, 1 Aug 2017 22:15:50 +0200
- To: ietf-http-wg@w3.org
Hi, I would like to discuss an idea how the 103 response could be treated in an intermediary cache. This is a copy of what I had posted at https://github.com/httpwg/http-extensions/issues/374, from where Patrick McManus pointed me to the mailing list. I hope this is the right place now. The proposal for the 103 Early Hints response contains a few examples referencing (probably caching) intermediaries. For example, to trigger a h2 server-push when an origin sends a 103 carrying Link headers. However, there is no explicit definition on what a cache or proxy server may or may not do with 103 responses. By definition, the informational response cannot have any own meta data: "A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational response itself". Obviously, 103 is not among the status codes cacheable by default defined in RFC7231 6.1. Furthermore the response cannot contain an entity body and it must be considered an intermediate response as the final response is still to come. I assume all that forbids storing the 103 in a cache. Considering the objective to speed up Web site delivery, I would like to discuss the idea of adding a mechanism that would allow an intermediary cache to store data from the 103 response. In a CDN-like setup an edge-server first receives an HTTP request and forwards it to the origin. Let's say the final answer took a long time, was private and could not be stored in the cache. However, a 103 intermediate response was received in the mean time and forwarded to the client. For subsequent requests to the same URL (according to the cache key calculation…) the edge cache could send the cached 103 downstream to the client while the original request is sent upstream to the origin at the same time. I think this could be a very effective way to use waiting time. A similar situation was proposed at the end of section 2, where an "intermediary generates a 103 (Early Hints) response based on the header fields of a stale-cached response". However, this can only apply to cacheable content. But HTML documents are most often private. To avoid "guessing" in intermediaries, we could define a special Cache Control header field accompanying the 103 status, such as "Early-Hint-Control". An origin could then define a 103 to be cacheable in a proxy server or cache. For subsequent requests the stored 103 could be sent downstream regardless of whether the final response is public or private. The header field could follow the Cache-Control semantics. The "public" and "max-age=N" directives seem appropriate. A proxy server would have to store the Early Hint information apart from regular responses (e.g. 200) to not confuse it with a final response. When the field "Early-Hint-Control: public" is not present, the 103 response should not be stored. Do you think this idea is worth to be considered? Best regards, Felix -- Felix Hassert Cologne, Germany
Received on Tuesday, 1 August 2017 20:16:16 UTC