Re: http/1.1 requirements

Robert Collins wrote:

> What SHOULD directive are you referring to? 15 is MUST - I used
> conditionally compliant - and I shouldn't have as per the definiation of
> conditionally compliant.

None. I am referring to terminology.

An implementation can be conditionally compliant with a MUST by having
it implemented in at least one configuration. If so then the
implementation is compliant with the RFC in those configurations only.
In all other configurations is is not compliant with the RFC (not even
conditionally compliant).

An implementation can also be conditionally compliant with the RFC as a
whole. If so, then there might be a number of SHOULD that is not
implemented, or (in my view) one or more of the above usage
restrictions.

> Are you saying we meet 18 & 19, or we do not meet 18 & 19?
> 18 and 19 are MUST requirement's, so although they are a exception to 17,
> they are not an option for implementation..

We meet them. Was I was intending was that we does not meet 17 as
expressed in the list due to the requirements of 18 and 19.

> But they are:
>
> Note the following requirements "on the note itself"
> a) it applies to transparent proxies only
> b) it applies to changing the request being sent upstream, not to comparing
> for equality
>
> so the ~ and %7e should be identical for squid's _comparison_ purpose. We
> shouldn't alter the abs_path in the request in transparent mode however, and
> we can if we wish to when acting as a normal proxy.

Squid normally has the intent of being a transparent proxy for the
subset of HTTP it supports.

There is no such thing as a "normal" proxy in the RFC. Either the proxy
is transparent or non-transparent. Examples of non-transparent proxies
are:

a) Squid using a redirector to alter the requested URLs
b) Image-transforming proxies for reducing bandwidth usage of images
over slow links.
c) Translating proxies
d) Buggy proxies unintentionally doing any of the above or related
operations.

And I still do not agree with your view to 100%.

Example:

A cache validation query for
http://squid.sourceforge.net/~hno/

should not return or match a cached object for
http://squid.sourceforge.net/%7Ehno/

just as it should not transform the URL when forwarding the request.
Serving objects from the cache is kind of a forwarding mechanism except
that the server isn't really contacted but a previous reply is replayed.

This is ofcourse unless there is some other critiera which makes the
objects identical regardless of the URL, but I don't think HTTP has any
such criterias.

For the purpose of invalidating cache content I do agree that they
should compare equal, but not for content delivery operations.

Please note that all uses of a cache is a MAY, while some invalidations
is SHOULD/MUST. My reasoning builds on this, the note and "be generous
in what you accept".

/Henrik
Received on Wed Oct 25 2000 - 02:40:25 MDT