103 Early Hints and Caching Intermediaries

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