Re: [RFC] cache architecture

tor 2012-01-26 klockan 13:32 +1300 skrev Amos Jeffries:
>
> We are wholly dependent on the server or client providing
> cache-controls that workaround the sync issues. So long as those
> controls and the purge are obeyed correctly *when received* I call it
> compliant.

Well, the things we talk about here is the same as purge, but implicit
such as effect of other requests.

GET /some/file

200 OK
ETag: "abc"

PUT /some/file

204 Created
ETag: "def"

[implicit purge of /some/file required]

[some time passes]

GET /some/file
If-None-Match: "def"

Here returning "abc" is a violation, and for good reasons.

> _compliant_, not necessarily good or workable. Just compliant.

Being compliant with IETF RFCs is all about being good and workable.
Being complaint just for the sake of the wording is pure nonsense and is
in fact non-compliant.

> In the same way that rejecting requests without Host: is compliant. But
> not always workable.

When is it not workable for HTTP/1.1?

I agree the rule as written is stupid (Host header should not be needed
if the URL is fully qualified in itself), but it is there and is
enforced as required by everyone that matters.

Note: The Host header requirement is only for HTTP/1.1. Host header do
not even exists in HTTP/1.0 other than as an optional extenson header.

Regards
Henrik
Received on Thu Jan 26 2012 - 18:59:12 MST