Re: http/1.1 requirements

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Wednesday, October 25, 2000 7:32 PM
Subject: 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.

Yup I used the wrong term about 3 mails back - sorry for the confusion (I
get the terms now (and did then) but was tired when writing :-[ )

> > 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.

18 & 19 now listed as "we do". (I'll upload shortly)
do we do case-insensitive compares (outside of the exceptions in 18 & 19?)
in which case 17 can be marked as does now. My list was a little brief
there - I missed using the implied default port number for the URI.

> > 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.

<flamebait mode> So why do we support authentication, redirection &
anonymity filtering? </flamebait mode>
I made an assumption when I read - that squid's "transparent" mode was
equivalent to rfc 2616 transparent operation. It's not though as I can see
now I am reading the text again. Doh.

> 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%.
>

I can see why - normal <> non-transparent :-]

> 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/
>

I'm not sure that it shouldn't. The Client will be treating them as equal
right? so the client may receive %7e and then send a HEAD for ~ in the next
user session. What gets me is the explicit 3.2.3 text more than the concepts
behind it. Is there someone on the RFC team we can ask for clarification?

> 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.

The issue that could arise is on revalidation. We can't send the
"normalised" uri, we have to send the one the client gave us, but we can't
add Etags for validation if the client request URI<>the cached URI.

> 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.

Agreed 100%

Why don't we do that then? It was one of the things nagging at me and I'm
happy with that aproach - invalidate anything with the same canonical URI,
but only deliver literal matching URI's.

Rob

> 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 - 03:57:08 MDT