Re: http/1.1 requirements

Hi replies in the body below. But first:
Is Bugzilla suitable to run the list on? and if so which one - sourceforge
or squid-cache.org

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Tuesday, October 24, 2000 9:07 AM
Subject: Re: http/1.1 requirements

> Robert Collins wrote:
>
> > > 15: Conditionally compliant. Can be violated by the use of
redirectors.
> >
> > conditionally compliant means we follow MUST and MUST NOT's but not all
the
> > SHOULD and SHOULD NOT's. So we aren't compliant. Can users use
redirectors
> > but force squid to prevent the hostname-in-fqdn request changing? Or do
we
> > simply say "squid w/o redirectors is conditionally compliant"
>
> Squid is conditionally compliant with this section. The condition is
> that redirectors are not used. Without removing the redirector interface
> we have to live with this, and when specifying compliance it must be
> noted that Squid is compliant provided no redirectors are used to
> rewrite the host component, just as the not implemented SHOULD must be
> specified..

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.

> The primary use of the redirector interface is just to rewrite the
> domain component of the URL, and this is not likely something we will
> remove only because of HTTP compliance. However, if
> --disable-http-violations is in effect then this should be enforced I
> think.

Yes I Agree. Perhaps we should have a list of everything that needs to be
shutdown/turned on to be rfc compliant, and then allow them to be
individually turned on or off as well - with the
global --disable-http-violations taking precedence? (And perhaps this should
be a squid.conf option)

> > > 16: Optional. Done when using the append_domain directive.
> > >
> > > 17: Compliant, except for 18 and 19.
>
> Which is compliant, as these are exceptions in the RFC, not specific to
> the Squid implementation.

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

> > > 20: Not applicable to proxies I think. Not done. See note at the end
of
> > > section 5.1.2.
> >
> > It's applicable to the extent of comparing entities to determine if they
can
> > be compared using strong or weak comparison see also Content-Location or
> > Location.
>
> I fail to see how you can apply the result of any such comparisation
> without violating the note. If you do then I se an apparent risk of
> having implicit transformations of the URL.
>
> For a proxy
> http://sourceforge.net/~hno/
> and
> http://sourceforge.net/%7Ehno/
> is completely different URLs
>
> for all other HTTP agents (clients and servers) they SHOULD be
> identical.. but there might be servers not understanding this and is why
> proxies are not allowed to assume they are.
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

Section 3.2.3 covers this:
<!--StartFragment-->
   Characters other than those in the "reserved" and "unsafe" sets (see
   RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.

   For example, the following three URIs are equivalent:

      http://abc.com:80/~smith/home.html
      http://ABC.com/%7Esmith/home.html
      http://ABC.com:/%7esmith/home.html
==
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.

 Rob
Received on Wed Oct 25 2000 - 01:53:54 MDT