New Version Notification for draft-nottingham-cache-header-00.txt

Discussion:

Mark Nottingham

2018-09-07 06:44:46 UTC

FYI; IMO it's past time to standardise x-cache and have a real spec for it.

This is a straw-man, based on a bit of research on existing implementations.

Pretty version at:
https://mnot.github.io/I-D/cache-header/

Comments? I think the primary audience here is proxy cache and CDN vendors, and their users.

Cheers,

Subject: New Version Notification for draft-nottingham-cache-header-00.txt
Date: 7 September 2018 at 4:41:52 pm AEST
A new version of I-D, draft-nottingham-cache-header-00.txt
has been successfully submitted by Mark Nottingham and posted to the
IETF repository.
Name: draft-nottingham-cache-header
Revision: 00
Title: The Cache HTTP Response Header
Document date: 2018-09-07
Group: Individual Submission
Pages: 7
URL: https://www.ietf.org/internet-drafts/draft-nottingham-cache-header-00.txt
Status: https://datatracker.ietf.org/doc/draft-nottingham-cache-header/
Htmlized: https://tools.ietf.org/html/draft-nottingham-cache-header-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-nottingham-cache-header
To aid debugging, HTTP caches often append headers to a response
detailing how they handled the request. This specification codifies
that practice and updates it for HTTP's current caching model.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat

--
Mark Nottingham https://www.mnot.net/

Thomas Peterson

2018-09-07 15:26:14 UTC

Permalink

I'm very much in favour of this, thanks Mark.

However, the draft doesn't expose a cache-action where a previous request is causing an update in still progress and is serving stale (for example, this is defined in nginx's UPDATING state). I think this should be added, perhaps as "HIT_REFRESH_UPDATING".

Also, no server I've found exposes a value that aligns with "ERROR", how might a 502/504 response code correlate to this, and should this draft specify these response codes be used as a 200 OK along with cache-action of "ERROR" doesn't make sense to me.

Regards

From: Mark Nottingham <***@mnot.net>
Date: Friday, 7 September 2018 at 07:48
To: HTTP Working Group <ietf-http-***@w3.org>
Subject: Fwd: New Version Notification for draft-nottingham-cache-header-00..txt
Resent-From: <ietf-http-***@w3.org>
Resent-Date: Fri, 07 Sep 2018 06:45:18 +0000

FYI; IMO it's past time to standardise x-cache and have a real spec for it.

This is a straw-man, based on a bit of research on existing implementations..

Pretty version at:
  https://mnot.github.io/I-D/cache-header/

Comments? I think the primary audience here is proxy cache and CDN vendors, and their users.

Cheers,

Begin forwarded message:

From: mailto:internet-***@ietf.org
Subject: New Version Notification for draft-nottingham-cache-header-00.txt
Date: 7 September 2018 at 4:41:52 pm AEST
To: "Mark Nottingham" <mailto:***@mnot.net>

A new version of I-D, draft-nottingham-cache-header-00.txt
has been successfully submitted by Mark Nottingham and posted to the
IETF repository.

Name: draft-nottingham-cache-header
Revision: 00
Title: The Cache HTTP Response Header
Document date: 2018-09-07
Group: Individual Submission
Pages: 7
URL:            https://www.ietf.org/internet-drafts/draft-nottingham-cache-header-00.txt
Status:         https://datatracker.ietf.org/doc/draft-nottingham-cache-header/
Htmlized:       https://tools.ietf.org/html/draft-nottingham-cache-header-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-cache-header

Abstract:
  To aid debugging, HTTP caches often append headers to a response
  detailing how they handled the request. This specification codifies
  that practice and updates it for HTTP's current caching model.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at http://tools.ietf.org.

The IETF Secretariat

--
Mark Nottingham https://www.mnot.net/

Mark Nottingham

2018-09-08 08:32:51 UTC

Permalink

Hi Thomas,

Thanks.

My initial thought is that HIT_STALE covers the case you describe (which sounds a lot like RFC5861 stale-while-revalidate).

I could see adding a parameter that indicates that the cache intends to update the entry asynchronously in the near future; would that work?

Cheers,

Post by Thomas Peterson
I'm very much in favour of this, thanks Mark.
However, the draft doesn't expose a cache-action where a previous request is causing an update in still progress and is serving stale (for example, this is defined in nginx's UPDATING state). I think this should be added, perhaps as "HIT_REFRESH_UPDATING".
Also, no server I've found exposes a value that aligns with "ERROR", how might a 502/504 response code correlate to this, and should this draft specify these response codes be used as a 200 OK along with cache-action of "ERROR" doesn't make sense to me.
Regards
Date: Friday, 7 September 2018 at 07:48
Subject: Fwd: New Version Notification for draft-nottingham-cache-header-00.txt
Resent-Date: Fri, 07 Sep 2018 06:45:18 +0000
FYI; IMO it's past time to standardise x-cache and have a real spec for it.
This is a straw-man, based on a bit of research on existing implementations.
https://mnot.github.io/I-D/cache-header/
Comments? I think the primary audience here is proxy cache and CDN vendors, and their users.
Cheers,
Subject: New Version Notification for draft-nottingham-cache-header-00.txt
Date: 7 September 2018 at 4:41:52 pm AEST
A new version of I-D, draft-nottingham-cache-header-00.txt
has been successfully submitted by Mark Nottingham and posted to the
IETF repository.
Name: draft-nottingham-cache-header
Revision: 00
Title: The Cache HTTP Response Header
Document date: 2018-09-07
Group: Individual Submission
Pages: 7
URL: https://www.ietf.org/internet-drafts/draft-nottingham-cache-header-00.txt
Status: https://datatracker.ietf.org/doc/draft-nottingham-cache-header/
Htmlized: https://tools.ietf.org/html/draft-nottingham-cache-header-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-nottingham-cache-header
To aid debugging, HTTP caches often append headers to a response
detailing how they handled the request. This specification codifies
that practice and updates it for HTTP's current caching model.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at http://tools.ietf.org.
The IETF Secretariat
--
Mark Nottingham https://www.mnot.net/

--
Mark Nottingham https://www.mnot.net/

Thomas Peterson

2018-09-10 05:30:22 UTC

Permalink

That'll work.

Regards

-----Original Message-----
From: Mark Nottingham <***@mnot.net>
Date: Saturday, 8 September 2018 at 09:32
To: Thomas Peterson <***@gmail.com>
Cc: HTTP Working Group <ietf-http-***@w3.org>
Subject: Re: New Version Notification for draft-nottingham-cache-header-00.txt

Hi Thomas,

Thanks.

My initial thought is that HIT_STALE covers the case you describe (which sounds a lot like RFC5861 stale-while-revalidate).

I could see adding a parameter that indicates that the cache intends to update the entry asynchronously in the near future; would that work?

Cheers,

--
Mark Nottingham https://www.mnot.net/

Alessandro Ghedini

2018-09-10 09:24:43 UTC

Permalink

This seems like a useful thing. Now to the bikeshedding: "Cache" seems a bit
too generic to me, "Cache-Status" maybe?

Also agree that the "ERROR" cache-action seems redundant given that we already
have ways to signal errors with status codes.

Cheers

Alex Rousskov

2018-09-10 16:21:05 UTC

Permalink

Post by Alessandro Ghedini
Also agree that the "ERROR" cache-action seems redundant given that we already
have ways to signal errors with status codes.

The client receives only one status code. While working on the client
request, the proxy may encounter _and_ work around both internal and
external errors, responding with 200 (OK). Today, such encounters and
workarounds are sometimes reflected in super-actions like
MISS_REFRESH_FAIL_OLD. It would be much better to list them as
individual (failed) actions with individual error details.

Alex.

Mark Nottingham

2018-09-17 18:30:10 UTC

Permalink

Post by Alessandro Ghedini

This seems like a useful thing. Now to the bikeshedding: "Cache" seems a bit
too generic to me, "Cache-Status" maybe?

I used "Cache" because current practice is using "X-Cache". Happy to bikeshed on other names :)

Post by Alessandro Ghedini
Also agree that the "ERROR" cache-action seems redundant given that we already
have ways to signal errors with status codes.

Yes. That's a discussion worth digging into; I've got another spec in the wings for that...

Cheers,

--
Mark Nottingham https://www.mnot.net/

Alex Rousskov

2018-09-10 16:13:36 UTC

Permalink

Post by Thomas Peterson
FYI; IMO it's past time to standardise x-cache and have a real spec for it.
This is a straw-man, based on a bit of research on existing implementations.
https://mnot.github.io/I-D/cache-header/
Comments? I think the primary audience here is proxy cache and CDN
vendors, and their users.

If we are to standardize X-Cache, then we should be mindful of the trap
created by early implementations that thought a single action value can
adequately relay what has happened at the proxy:

1. The obvious HIT and MISS actions came first.

2. Then we quickly discovered that a "we found it in the cache" HIT
action is often followed by a REFRESH action (and a resulting MISS from
the proxy-server traffic point of view). HIT_REFRESH... concatenations
were used to combat this.

3. Realizing that even fresh cache HITs may become misses due to various
protocol requirements and internal problems, some added X-Cache-Lookup
that was dedicated to the first (and often critical for triage) cache
lookup, depicting what happened to that HIT later in X-Cache.

4. Then flash crowds and collapsed forwarding solutions came along. Now,
a single client HIT or MISS request could cause even more transactions,
some of which could be cache hits, some could be revalidations or even
errors. Some added COLLAPSED_HIT_REFRESH... and/or other variants. This
concatenation approach still loses a lot of info, but it highlights the
fact that a lot of info could be lost by including the COLLAPSED tag.

If the goal here is to standardize the current status quo, then the
document should cover Cache-Lookup and COLLAPSED tags (and/or their
variations).

If the goal here is to standardize a scalable solution based on the
current experience, then we should combine Cache-Lookup and Cache while
enumerating individual cache actions as separate same-node entries
(instead of trying to merge them into a single FOO_BAR_BAZ super-action
summary for one node).

Cheers,

Alex.

Poul-Henning Kamp

2018-09-11 10:10:20 UTC

Permalink

--------

Post by Mark Nottingham
FYI; IMO it's past time to standardise x-cache and have a real spec for it.

Agreed, and I think I can promise Varnish Cache support in some shape or form.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Mark Nottingham

2018-11-13 04:57:47 UTC

Permalink

Hi Kazuho!

Hi Mark,
Thank you for the draft.
I like the Cache header it because it standardizes what we have been
doing, and it has clear structure that can be used by the client to
collect stats.
OTOH, I wonder how we should use it in conjunction with Server-Timing header.
In my view, both the Cache header and the Server-Timing header allows
caches and intermediaries to set arbitrary information related to
processing.
For example, I think the example described in the I-D (quoted below
using separate Cache header for each element) can be represented also
by using the Server-Timing headers as show below.
Cache: HIT_FRESH; node="reverse-proxy.example.com:80";
key="https://example.com/foo|Accept-Encoding:gzip"
Cache: HIT_STALE; node="FooCDN parent"; fresh=-45; age=200; latency=3,
Cache: MISS; node="FooCDN edge"; fresh=-45; age=200; latency=98
Server-Timing: hit-fresh; node="reverse-proxy.example.com:80";
key="https://example.com/foo|Accept-Encoding:gzip"
Server-Timing: hit-stale; node="FooCDN parent"; fresh=-45; age=200; dur=3
Server-Timing: miss; node="FooCDN edge"; fresh=-45; age=200; dur=98
I do not think that having both Cache and Server-Timing is a bad idea.
However I would like to see a clarification on how they should be
used, especially because their features are IMO overlapping
(especially the `latency` and `dur` attributes).

Server-Timing is designed for *application specific* metrics; it's automagically slurped up by browsers for inclusion in their developer tools, etc. Effectively, it doesn't have any semantics beyond "whatever metrics you want to put in here will show up over there."

Cache is designed for generic HTTP caching semantics; its value is in that its values mean the same no matter what application you use them with. By default browser dev tools don't display it, but there's no reason they couldn't if they wanted to -- and because it has defined semantics, if they did, they'd be able to integrate it into what they show the developer more deeply / accurately.

If we used Server-Timing for this use case, we'd be effectively squatting on a bunch of metric names for applications, and hoping we wouldn't have a clash. I think encouraging CDNs, reverse proxies and forward proxy caches to use Server-Timing is Probably Not Great.

Also -considering that 95% of the effort here is going to be defining the semantics, I'm not too worried about the extra effort of defining a new header (especially since we're using Structured Headers :)

Cheers,

Post by Mark Nottingham
FYI; IMO it's past time to standardise x-cache and have a real spec for it.
This is a straw-man, based on a bit of research on existing implementations.
https://mnot.github.io/I-D/cache-header/
Comments? I think the primary audience here is proxy cache and CDN vendors, and their users.
Cheers,
Subject: New Version Notification for draft-nottingham-cache-header-00.txt
Date: 7 September 2018 at 4:41:52 pm AEST
A new version of I-D, draft-nottingham-cache-header-00.txt
has been successfully submitted by Mark Nottingham and posted to the
IETF repository.
Name: draft-nottingham-cache-header
Revision: 00
Title: The Cache HTTP Response Header
Document date: 2018-09-07
Group: Individual Submission
Pages: 7
URL: https://www.ietf.org/internet-drafts/draft-nottingham-cache-header-00.txt
Status: https://datatracker.ietf.org/doc/draft-nottingham-cache-header/
Htmlized: https://tools.ietf.org/html/draft-nottingham-cache-header-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-nottingham-cache-header
To aid debugging, HTTP caches often append headers to a response
detailing how they handled the request. This specification codifies
that practice and updates it for HTTP's current caching model.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
--
Mark Nottingham https://www.mnot.net/

--
Kazuho Oku

--
Mark Nottingham https://www.mnot.net/

Kazuho Oku

2018-11-14 12:48:46 UTC

Permalink

Hi Mark,

Thank you for the clarifications.

I agree that we need a structured way to emit what's happening in the
caches, and that the proposed Cache header is in the approach we
should adopt.

I still feel it to be unfortunate for the fact that the features
overlap between the two header fields, but hopefully browsers would
add JavaScript API to the Cache header and then things would become
optimal.

Post by Mark Nottingham
Hi Kazuho!

Server-Timing is designed for *application specific* metrics; it's automagically slurped up by browsers for inclusion in their developer tools, etc. Effectively, it doesn't have any semantics beyond "whatever metrics you want to put in here will show up over there."
Cache is designed for generic HTTP caching semantics; its value is in that its values mean the same no matter what application you use them with. By default browser dev tools don't display it, but there's no reason they couldn't if they wanted to -- and because it has defined semantics, if they did, they'd be able to integrate it into what they show the developer more deeply / accurately.
If we used Server-Timing for this use case, we'd be effectively squatting on a bunch of metric names for applications, and hoping we wouldn't have a clash. I think encouraging CDNs, reverse proxies and forward proxy caches to use Server-Timing is Probably Not Great.
Also -considering that 95% of the effort here is going to be defining the semantics, I'm not too worried about the extra effort of defining a new header (especially since we're using Structured Headers :)
Cheers,

--
Kazuho Oku

--
Mark Nottingham https://www.mnot.net/

--
Kazuho Oku