Re: http/1.1 requirements

Thanks for the prompt review!
Perhaps Bugzilla on S/F now we have a base list?

I have updated the checklist (on sourceforge only). Not that where squids
current behaviour is correct with respect to HTTP/1.0 but will not be with
respect to 1.1 I have said not done (it is a checklist) but included your
comments in the notes.

I forgot to mention this before, but I suggest we only "tick" entries once
all the http/1.1 code is in place and all the status lines are does now or
"will not do". That way when we check stuff we shouldn't have regression
worries.

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

> Robert Collins wrote:
>
> > http://squid.sourceforge.net/squidhttp1.1.htm
>
>
> 6: Does now (HTTP/1.0)
>
> 7: Done, by simply downgrading the protocol number. No attempts in
> downgrading the request is done.

Then we are faulty. We should be downgrading the request - checking it's
compliance with the HTTP/1.0 rules, or returning an error, or switching to
tunnel mode.

> 8: Does now. HTTP/0.9 is upgraded to HTTP/1.0 if support for 0.9 is
> enabled (and fixed).

so this will be not done w.r.t. 1.1

> 9: Does now. All responses from Squid is using Squid's HTTP version.

We don't check that we are using the same major version do we? 0.9 clients
should get a 0.x response.

> 11: Not compliant. Squid puts an upper limit on the URI length.

Do we want to change this?

> 12: Not compliant. Redurns some other error code.
>
> 13: Compliant. Squid always uses it's host name in generated URLs.
>
> 14: Done when forwarding the request to a origin site. Not done when
> forwarding to another proxy.
>
> 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"

> 16: Optional. Done when using the append_domain directive.
>
> 17: Compliant, except for 18 and 19.
>
> 18: Compliant.
>
> 19: Compliant.
>
> 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.

> 26: Not compliant. Charset is not specified in the HTTP headers even
> when it should (i.e. error pages using national characters and such).
>
> 27, 28, 29: Not done. see 26.
>
> 30: Don't think this applies to proxies.. Squid does not render
> documents.

Altered to be "for the client"

> 32: Not applicable to software. It is a administrative requirement.
>
> 33: see 32.
>
> 34: not in the HEAD version. Compliant in the "te" branch I think.
>
> 35: see 34.
>
> 36: see 30.
>
> 37: see 34, maybe.
>
> 38: see 34, maybe.
>
> 39: see 34. Probably not done, but maybe in chunked<->chunked transfer
> where such headers are sent by the origin server.
>
> 40: see 39.
>
> 41: see 34.
>
> 42: see 34. unknown.
>
> 43: compliant for headers generated by Squid.
>
> 44: not done
>
> 45: compliant for locally generated content.
> does not apply to transparent proxies for proxied content.
>
> 46: see 45.
>
> 47: not compliant. See 26.
>
> 48: compliant. Squid does not generate any multipart entities, or are
> allowed to touch this for proxied entities.
>
> 49, 50, 51: see 48.
>
> 52: unsure.
>
>
> [now I am getting tired ;-)]
>
> Hmm.. I think we should attempt to throw these criterias into a SQL
> database on sourceforge to allow on-line updates, sorting and such fancy
> things.. they do provide PHP + MySQL which should be a quite good fit
> for this job..
>
> /Henrik
>
>
Received on Sun Oct 22 2000 - 15:31:05 MDT