Subject: 103 Early Hints and Caching Intermediaries

From: Felix Hassert <[email-masked]>
Date: Tue, 1 Aug 2017 22:15:50 +0200

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

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 1 Aug 2017 23:04:16 +0200

Hi,

On Tue, Aug 01, 2017 at 10:15:50PM +0200, Felix Hassert wrote:
(...)
> present, the 103 response should not be stored.

Why not simply use cache-control and define its validity with 103 ? I think
that your use case makes a lot of sense, though in terms of cache, it's
very special in that this cache would probably aggregate all Link header
fields retrieved over possibly multiple 103 responses, never any payload,
and would return them upon further requests.

Regards,
Willy

---

From: Felix Hassert <[email-masked]>
Date: Wed, 2 Aug 2017 23:40:48 +0200

Hi Willy,

you are right. It is probably not very useful to send a Cache-Control header in a 103 to
announce the cacheability of the upcoming response in advance. So we could consider
the header "free" to define it to be applied to the 103 itself.

An example could look like this:

 HTTP/1.1 103 Early Hints
 Cache-Control: public, max-age=86400
 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
 Cache-Control: private
 Set-Cookie: …

Or did you think of a cache control extension as in RFC 7234 #5.2.3? Something like
this:

 Cache-Control: private, early-hint="intermediary, 3600"

(early-hint="public, max-age=3600" would be more readable, but probably dangerously
to mis-parse).

Best regards,
Felix

> Am 01.08.2017 um 23:04 schrieb Willy Tarreau <[email-masked]>:
> 
> Hi,
>