Re: New Version Notification for draft-cdn-loop-prevention-00.txt

On 02/07/18 20:19, Mark Nottingham wrote:
> Hi Thomas,
> 
> That's a good question. The focus is on CDNs here because it's a problem and a solution that's pretty specific to them.
> 
> In other words, it's easy to prevent loops when you control all of the layers (or can closely coordinate with them); you just define a loop prevention mechanism. AFAIK most CDNs do this internally already. 
> 
> The problem is when you a) have multiple uncoordinated layers (like CDNs), and b) they can be configured by a potential attacker, or misconfigured by a well-meaning customer who's using multiple CDNs. 
> 
> In that case, the CDNs need to agree on a mechanism that can prevent loops amongst them; once we settle on it, we can prevent customer configuration from modifying that header field, and prevent any attack / misconfiguration.
> 
> In theory it could be used by others. However, given the misuse of Vary that the draft cites, I'm reluctant to make its use too broad; if sites start doing other things with it, we won't be able to use it in CDNs, and we'll have to create Yet Another Header.
> 
> Does that make sense?
> 

s/Vary/Via/

But no, the rational for adding a new header does not make much sense
yet. There is already Forwarded header created for this same use-case
(amongst others) overlapping with Via.

And why not push to get the problematic servers fixed instead of
polluting HTTP header space with more features everybody with middleware
has to support?

Amos

Received on Monday, 2 July 2018 08:49:28 UTC