Re: RFC2616 errata: HTTP-Version should be case-sensitive

On Mon, 16 Sep 2002, Roy T. Fielding wrote:

> No, they don't.  It just seems that way because you have no means of
> determining their internal interpretation.  Apache will consider the
> client to be a broken HTTP/1.0, or simply respond in HTTP/0.9.

I did not (and cannot) check all the internals, but I am sure that
those intermediaries that are tested for (and interested in) HTTP
compliance will support "http/1.1" strings since it will be one of the
test cases. I cannot speak for Apache, but the primary mod_proxy
developer does get our "RFC 2616 violations" reports.

> Errata is for fixing specification errors.  Given that I wrote that
> section of the specification, I know it is an error, and therefore
> it is errata

A mismatch between author's intention and RFC wording is not
necessarily an error. Authors intention is always secondary to the
released RFC. Intentions are somewhat important only when the RFC is
not clear or presents implementation problems. The current wording in
question is very clear, unambiguous, and presents no more problems
than parsing the rest of HTTP control structures, right?

> unless someone can explain why it is a necessary "feature".

It is not a feature, it is an "absence of an exception" (an exception
that you want to make). The current format is simply consistent with
other HTTP parsing rules. Marking just this particular definition as
an error needs more justification than lack of server-side support,
IMHO. If lack of support is important, the protocol would require a
major revision (to be consistent) since many HTTP features are not
widely supported.

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

Received on Tuesday, 17 September 2002 00:35:53 UTC