In addition, having Expires set to a date in the past in not the same as "Cache-Control: no-cache, private". The latter instructs CDNs not to cache the file whereas the former doesn't (CDN is allowed to cache the file and revalidates with the origin).

Disclosure: I work at cloudflare.

You can do that without the Expires header, though.

    Cache-Control: max-age=0, s-maxage=3600

...or similar permutations.

Yup just want to point out the replacement suggested in the blog is incorrect. Simply max-age=0 should be sufficient to emulate Expires: past date

Your use of the term "attack" seems to imply that a malicious client can trigger circular request loops by using a cleverly forged request. But I cannot understand how it could happen, unless the proxy servers are misconfigured. Am I missing something?

The link above describes numerous proxies as not so much misconfigured as miscoded. That is, no configuration should cause a proxy to not apply a Via or to ignore its own Via. Presumably the attacker would be a malicious proxy customer rather than a malicious client. If the proxy customer is not considered as a monolith, then actually control of just one proxy's configuration is enough to turn a chain into a loop.

I still feel like I'm missing something, because it sounds like "If an attacker can rewrite your configuration inside CDN, bad things will happen."

I mean, Via might be useful as a safety check against mistake, but I'm not getting the security angle.

The threat is a DOS against a group of CDNs as a whole. Particular CDN customers are only vulnerable to the extent that they require an affected CDN's services. If the CF link isn't clear, click through to the paper they reference:

http://www.icir.org/vern/papers/cdn-loops.NDSS16.pdf

But that's all delicately balanced on trusting the Via headers. If you are under attack from someone malicious then that seems unwise.

It's like relying on the From: header in an e-mail.

That's not the point here. It's an adversary getting two CDNs to loop eachother and launching an attack that way.

If CDN A proxies requests to CDN B and CDN B proxies requests to CDN A then those two will DoS eachother fairly quickly.

There is no attacker inbetween to strip the Via, that would be counterproductive to the attack.

Email has this too; the Received: header. If you manage to get a loop between two MTAs going they will detect it by seeing themselves in the Received: header list.

If other CDNs are removing your Via header, then other CDNs are the adversary, but now we're in Crazy Town because in that case they are DOSing themselves as much as they are DOSing you. The threat discussed here is from malicious CDN customers.

The proper check is in routing tables and/or firewalls.

> If you are under attack

If. Much, if not most, server software is written under the implicit assumption that it will not be under attack.

But these particular Via headers are applied by the CDNs, not by an end user.

What a terrible stance for a company like Fastly to take:

More debatable perhaps is Via, which is required (by RFC7230) to be added to the response by any proxy through which it passes to identify the proxy. This can be something useful like the proxy’s hostname, but is more likely to be a generic identifier like “vegur”, “varnish”, or “squid”. Removing (or not setting) this header is technically a spec violation, but no browsers do anything with it, so it’s reasonably safe to get rid of it if you want to.

Actually, it isn’t “debatable,” since the debate occurred, and a decision was made, and published. That’s what RFCs are for.

To ignore them with such wanton disregard speaks volumes.

Edit: to clarify, I didn't mean that RFCs should not be debated at all, only that disregarding this because "no browsers do anything with it" didn't seem like a good justification or stance.

Not really. Standards are nice, but as time goes on, things change, and we should NEVER only change things 'once a standard says so'. The web is an ever evolving platform, and standards are loosely respected these days anyway. Heck, browsers aren't a standard themselves!

By that logic there isn't any point to standards at all. If we all are supposed to ignore them when we feel like it then what's the point of having them at all?

If there is a standard published for something, follow it or publish your own RFC. Don't just nitpick the bits you want and break clients in the process.

They're provided as guidance. They aren't some kind of internet law. Sometimes contravening standards is harmful; sometimes it's helpful. It's not productive to point at them as if they were dispositive in debates.

There is a bit more to it though: When a vendor declares compliance to a standard and fails to implement it correctly, then the vendor can be held accountable, and a customer is in a much better position to negotiate a correction. For this reason, standards are also important from a legal perspective.

Nope. If web standards worked, the benefits would be a stable platform where you can easily create new software that both produced or consumed content without breaking anything.

Of course that isn't what is happening at all. Instead we're having the usual heap of politics and ever-faster update cycles. So I'd agree to say that web standards failed - but not that they were meant as a guidiance in the first place.

Not really. https://tools.ietf.org/html/rfc791 ^ Was burned in hardware all over the planet.

People play games with IP all the time.

Sure, but there isn't a big company with clout saying "Hey, you should deviate from RFC791".

I agree that standards can and should be replaced/amended to over time, but I kinda see what GP's point is getting at.

Dropping Via from a response is roughly in the same category as ignoring the TCP Urgent flag. Most widely used standards have vestigial bits.

A lot of hardware silently edits TOS flags, causing trouble with ECN and diff-serv...

Ignoring is usually fine. Dropping is not.

> Don't just nitpick the bits you want

<nitpick> Only people who like lice eggs nitpick the bits they want. Others pick-and-choose. </nitpick>

https://www.vocabulary.com/dictionary/nit

You, sir, have achieved a new level of pedantic.

I do disagree with the parent's wording that it isn't "debatable". At the same time, I think the point trying to be made is that the article disregards the debates made for it. This seems to show itself in the fact that the article talks mainly of how browsers do not use Via. The problem being that the debate around the RFC was for an entirely different use case. As per the RFC spec, a lot of it was around protocol capabilities.

Thus it may not be useful to the browser. But the article saying that its usage is debatable in this context is very wrong.

So then re-write and submit an RFC...or go to IETF and join a WG - be open to discussion and speak up about what needs changed.

A MUST is a MUST, in my opinion - and too often there are serious issues in (web) communication because people ignore them as they see fit.

In either event - no one is saying that you should wait to change an RFC (or wording in an RFC) until it's fully deprecated and completely not in use - but a lot of people use RFC's for researching issues, especially in areas they are not 100% familiar with. Coming across a MUST and seeing that some software vendor or hardware vendor doesn't follow it is all too common. This delays certain projects by weeks, sometimes longer, and costs the involved companies lots of money. RFC's exist for a reason...because the approved standards are just expected to be followed when creating new things.

Some things are just wrong. I've implemented SIP, a horrible standard. Lots of compatibility issues just from their insistence on a "human friendly" text format alone.

At any rate there's lots of things you just have to ignore, drop, reject, and otherwise muck about with in order to run a sane network. These standards are not written with software experience. They're written much in a vacuum and out of touch. This varies widely across RFCs so it might not apply to RFCs you like.

Example of a MUST for SIP and HTTP: line folding and comments in headers. Apart from being crap for performance (so much for being able to zero-copy a header value as just a pointer+len) there's zero legitimate use for these "features" of the syntax. Simply rejecting such messages is in your best interest as a network operator.

This specific point got me as well: I can't really get behind a company - especially a CDN company - telling people to break the specific because "no browsers don't do anything with it." That is, honestly, really bad advice and I can't take any of their other points seriously.

I think this blog is more of an editorial piece considering that fastly will insert two 'Via: 1.1 varnish' with shielding enabled plus a range of additional X- headers. :)

I actually read this whole thing as: we don't disable this ourselves. But if you're using us as the last layer before the user agent, you can dump this header. And our Varnish language makes it easy.

An RFC is a Request for Comments, an invitation to debate. Anyone can publish an RFC.

Right - then IETF adopts approved RFC's and publishes them as internet standards. What we're discussing in this thread are accepted / approved internet standards - not just some random RFC that some dude tossed up on a work group.

It’s not like there is some kind of internet police that’ll come after you if you don’t follow the RFCs, whether IETF approves them or not. You can decide to follow them all the way, partly or not at all.

Or you can debate them as much as you want, or even publish a new and improved version and perhaps people will decide to follow that instead. Or perhaps they’ll just do whatever they feel like.

lol... and then I come into work and find out from my colleague that actually Cloudflare now disables the Via header by default.

For those wanting the extra context around this decision:

There's a really important reason for not sending the Via header in the request: it disables compression, by default, in most major web-servers!

· nginx defaults gzip_proxied to "off", where 'proxied' is determined by the presence of the Via header: http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip...

· The same goes for IIS 7 & IIS 8 via noCompressionForProxies defaulting to "true" - https://docs.microsoft.com/en-us/iis/configuration/system.we...

· Apache's mod_deflate doesn't do this (thankfully).

This has an immediately negative impact on performance and, in many cases, cost: the origin server is sending more bytes over the wire, and network transit is often a non-trivial cost for those on AWS, Azure, et. al.

Akamai also has a post on this: https://community.akamai.com/community/web-performance/blog/...

Note: I used to work at Cloudflare, and believe they (we!) made the right decision here. There are other mechanisms that can be used to detect proxy loops, and there are also cases where customers may "stack" edge network vendors (migration, specific feature needs, application complexity).

PS: Hi David! :)

Very interesting link, thanks. I'm not too familiar with this area, but from my understanding of the article, Cloudflare are suggesting that all players in the game need to be compliant otherwise nobody wins

So is this Fastly article suggesting a different point of view?

Well, if one CDN doesn't respect it, it will probably soon find out :) So it's a self correcting problem.

The article mentions that Via is useful while the request is bouncing around among proxies, but isn't useful in responses, which is what the article is about.

They're talking about responses in which Via is technically 'required' but pretty useless. The blog post you linked seems to be about the use of the header in requests.

Wouldn't it be better to use the "Forwarded" header for this?

Why better?

Via is a MUST https://tools.ietf.org/html/rfc7230#section-5.7.1

Forwarded is OPTIONAL https://tools.ietf.org/html/rfc7239#section-4

Protecting against loops only works with MUST headers.

Additionally, Forwarded is only for requests, while Via is for both requests and responses.

Makes sense. Thanks!

How is Via different from “X-Forwarded-For”?

They are in different directions:

Via => proxy/organization name chain where the response came from

X-Forwarded-For => ip address chain where the request came from