ons 2006-12-13 klockan 08:51 -0500 skrev Brian Akins: > However, on an initial request (ie, non-conditional) we do not have an etag > from > the client, we only have info like Host, URI, Accept-*, etc. So, how would > the > cache identify which entity to serve in this case?
You have the URL and the "other" cached entities of that URL. It does not matter if the client request was a conditional or not. The conditions in the request is on the response to see if it should be a 200 or 304, not selectors on what entity to respond with. The selected response entity is always the same for the same request, with or without conditions. Obviously on the very first request for a given URL you have nothing, and that request is forwarded without any added condition. However, after that every Vary cache miss on that URL is a If-None-Match conditional to ask the server if any of the cached entity variants is applicable for the current request. > I have read it many times.. In our case - cnn.com, etc. - we have to decided > to > be RFC "compliant" from the client to the cache server. From the cache to > the > origin, however, we are not as concerned. And you are free to. A reverse proxy is by definition the origin server. How it finds the content is of no concern to the RFC, just happens to be HTTP and not plain files, NFS, database or whatever. > In a reverse-proxy-cache, this is not > a big deal. However, in a "normal forward-proxy-cache," where one does not > control both cache and origin, one must be more careful. Indeed. But on the other hand it's actually reverse proxy configurations which has pushed for 13.6 compliance in Squid as it's a lot easier for processing intensive servers to evaluate If-None-Match than to render the entity again, and when you depend on Accept-Language + Accept-Encoding + User-Agent the number of request combinations becomes quite significant, especially if there maybe only is two or three variants under the URL. Regards Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel
