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

From: Mark Nottingham <[email-masked]>
Date: Fri, 7 Sep 2018 16:44:46 +1000

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: [email-masked]
> Subject: New Version Notification for draft-nottingham-cache-header-00.txt
> Date: 7 September 2018 at 4:41:52 pm AEST
> To: "Mark Nottingham" <[email-masked]>
> 
> 
> 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 tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: Thomas Peterson <[email-masked]>
Date: Fri, 07 Sep 2018 16:26:14 +0100

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 <[email-masked]>
Date: Friday, 7 September 2018 at 07:48
To: HTTP Working Group <[email-masked]>
Subject: Fwd: New Version Notification for draft-nottingham-cache-header-00..txt
Resent-From: <[email-masked]>
Resent-Date: Fri, 07 Sep 2018 06:45:18 +0000

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

Pretty version at:

Cheers,

Begin forwarded message:

From: mailto:[email-masked]
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:[email-masked]>

Abstract:

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

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 8 Sep 2018 18:32:51 +1000

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,

> On 8 Sep 2018, at 1:26 am, Thomas Peterson <[email-masked]> wrote:
> 
> Subject: Fwd: New Version Notification for draft-nottingham-cache-header-00.txt

---

From: Thomas Peterson <[email-masked]>
Date: Mon, 10 Sep 2018 06:30:22 +0100

That'll work.

Regards

-----Original Message-----
From: Mark Nottingham <[email-masked]>
Date: Saturday, 8 September 2018 at 09:32
To: Thomas Peterson <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: New Version Notification for  draft-nottingham-cache-header-00.txt

    Hi Thomas,
    
    Thanks.

    
    Cheers,

---

From: Alessandro Ghedini <[email-masked]>
Date: Mon, 10 Sep 2018 10:24:43 +0100

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

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

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 10 Sep 2018 10:21:05 -0600

> 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.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 10 Sep 2018 10:13:36 -0600

> 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.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 11 Sep 2018 10:10:20 +0000

--------

>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
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Sep 2018 14:30:10 -0400

> On 10 Sep 2018, at 5:24 am, Alessandro Ghedini <[email-masked]> wrote:
> 

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

> 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,