Subject: Re: [Tools-discuss] moving/marking rfcdiff to not get cached by cloudflare

From: "Martin Thomson" <[email-masked]>
Date: Thu, 02 Jan 2020 13:28:52 +1100

On Wed, Jan 1, 2020, at 07:14, Michael Richardson wrote:
> 
> I construct URLs for rfcdiff, pointing it to my formatted txt file on github,
> against my DT -XX.txt file. This is now being cached, I assume by
> cloudflare.
> Being able to Shift-Reload on the tab to validate the changes is really useful.
> 
> I wonder if we can someone how mark the results as uncacheable?
> Or move rfcdiff to another name which isn't cached? or...?

Shift-Reload should mark the request as not drawing from cache.  But the response I see doesn't have any validity information.  That might mean that you might be getting heuristic caching.

That said, after testing this on [1], the time spent waiting (almost 3s) seems to indicate that no cache is involved.  A simple reload was enough to induce that delay, not the cache-busting shift-reload.  In this case, that means setting Cache-Control: max-age=0 on the request, which seems to be enough.

[1] https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-git-using-github.txt&url2=https://ietf-gitwg.github.io/using-github/draft-ietf-git-using-github.txt

---

From: Glen <[email-masked]>
Date: Wed, 1 Jan 2020 18:41:34 -0800

> > Or move rfcdiff to another name which isn't cached? or...?

Hi Michael -

Sorry if I'm missing a detail, but I'm not sure whether you're using
the IETF rfcdiff (www.ietf.org/rfcdiff) or whether you're using
Henrik's Tools servers (tools.ietf.org/rfcdiff) .  I can of course
only speak for the former.  If you're on www.ietf.org, I have reviewed
the Cloudflare configuration, and I can tell you that:

www.ietf.org/rfcdiff/*
www.ietf.org/tools/*

are both *NOT* cached.  That is to say Cloudflare is configured to
always pass those things through to our server without caching or
storage.

> That said, after testing this on [1], the time spent waiting (almost 3s) seems to indicate that no cache is involved.  A simple reload was enough to induce that delay, not the cache-busting shift-r…

+1

> [1] https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-git-using-github.txt&url2=https://ietf-gitwg.github.io/using-github/draft-ietf-git-using-github.txt

If, however, you are, as Martin is, using tools.ietf.org, then we'll
need to wait for Henrik to get back (I believe on the 6th) for him to
comment.

And, of course, the *sources* of your txt files might be cached on
their end - I have no idea, for example, what github might be doing...

Glen
--
Glen Barney
IT Director
AMS (IETF Secretariat)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Jan 2020 22:52:15 -0500

> Shift-Reload should mark the request as not drawing from cache.  But
    > the response I see doesn't have any validity information.  That might
    > mean that you might be getting heuristic caching.

...

    > https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-git-using-github.txt&url2=https://ietf-gitwg.github.io/using-github/draft-ietf-git-using-github.txt

Since I'm using https://raw.githubusercontent.com/ I wonder if the problem is
that the underlying file is being cached?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Jan 2020 22:53:15 -0500

Martin Thomson <[email-masked]> wrote:
    > [1]

Glen points out that you are using a different rfcdiff than I.
I will try that one next time.

---

From: Glen <[email-masked]>
Date: Wed, 1 Jan 2020 20:26:12 -0800

> that the underlying file is being cached?

I'm sure you already did this, but just for those reading...

~> host raw.githubusercontent.com
raw.githubusercontent.com is an alias for github.map.fastly.net.
github.map.fastly.net has address 151.101.0.133
github.map.fastly.net has address 151.101.64.133
github.map.fastly.net has address 151.101.128.133
github.map.fastly.net has address 151.101.192.133

https://www.fastly.com/ seems - only at first glance - to be something
similar to a CDN, so I'd say that you could be exactly right here.

Glen

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 2 Jan 2020 07:31:32 +0100

Inline:

> need to wait for Henrik to get back (I believe on the 6th) for him to

tools.ietf.org is not behind a CDN, and there is no caching going on.

> their end - I have no idea, for example, what github might be doing...

That could indeed be the issue.

	Henrik

> Glen
> --
> Glen Barney
> IT Director
> AMS (IETF Secretariat)
> 
> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]
>