Re: WGLC #363: rare cases

Mark Nottingham wrote:
> Those are reasons not to generate a LM, but they aren't specific to HTTP/1.0 -- agreed?

Sure.

> I can see dropping the last sentence and qualifying the remaining SHOULD with these sorts of reasons, but not retaining it.

Absolutely - explain, not ignore or gloss over.

There's actually another bit which does much the same thing  that
I've got on my list of quibbles:

RFC 2616 S13.10

   In order to prevent denial of service attacks, an invalidation based
   on the URI in a Location or Content-Location header MUST only be
   performed if the host part is the same as in the Request-URI.

httpbis-p6-cache S2.6

   However, a cache MUST NOT invalidate a URI from a Location or
   Content-Location response header field if the host part of that URI
   differs from the host part in the effective request URI (Section 5.5
   of [Part1]).  This helps prevent denial of service attacks.

It's never fully explained how such a denial of service attack would
manifest, nor how serious it could be. The immediate possibility is
being able to effectively clear a cache causing more load on the
origin that usual, or more transit from the cache than usual, but I
have difficulty seeing how that is a serious concern:

This basically requires a malicious origin to work. If the cache is
inside the control of the origin, then presumably the origin isn't
malicious.

If the cache is outside the control of the origin, then if the target
is a different origin it presumably has to be able to deal with
a reasonable level of uncached requests hitting it anyway. If the
target is the cache itself then (without the vhost check) we can
clear at most 2 unrelated URLs per incoming client request. But a
client could clear those URLs anyway by sending max-age=0 and dropping
the connection after the first body byte. This will cause many
implementations to drop the previously cached response and cease
storing the new one too.

So I don't see how malicious use of Location/Content-Location is
much worse than other techniques, and it's arguably harder to pull
off than a purely client driven attack.

I'm not suggesting dropping the vhost check here, it seems like a
reasonable idea, but the justification seems overblown.

John
--

Received on Wednesday, 27 June 2012 12:00:34 UTC