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

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 16 Sep 2002 17:13:04 -0700

RFC 2616 BNF defaults to case-insensitive for string literals:

    "literal"
       Quotation marks surround literal text. Unless stated otherwise,
       the text is case-insensitive.

but the HTTP version string is defined as

    The version of an HTTP message is indicated by an HTTP-Version field
    in the first line of the message.

        HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

    Note that the major and minor numbers MUST be treated as separate
    integers and that each MAY be incremented higher than a single digit.
    Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
    lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
    MUST NOT be sent.

Personally, I never had any intention that the "HTTP" be case-insensitive,
and I am not aware of any clients that send it lowercase, nor any server
that would accept it as lowercase.  Doing so is a waste of cycles.  So,
I'd like that paragraph above to say:

    The version of an HTTP message is indicated by an HTTP-Version field
    in the first line of the message.  HTTP-Version is case-sensitive.

Servers would still be allowed to process it as case-insensitive under
the general robustness principle, but clients are no longer given the
excuse of "But it says in the standard ...".

Cheers,

Roy T. Fielding, Chief Scientist, Day Software
                  ([email-masked]) <http://www.day.com/>

                  Co-founder, The Apache Software Foundation
                  ([email-masked])  <http://www.apache.org/>

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 16 Sep 2002 19:37:25 -0600 (MDT)

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

> Personally, I never had any intention that the "HTTP" be
> case-insensitive, and I am not aware of any clients that send it
> lowercase, nor any server that would accept it as lowercase.

Apache server and some proxies seem to handle "http/" just fine.

> Doing so is a waste of cycles.

True, but so are many (if not most) of the HTTP parsing requirements.
I would think that errata is for fixing errors, not optimizing.

If you disagree, should "implied LWS" and similar WasteOfCycles
requirements then be removed to optimize and simplify parsing?  Most
clients don't use and most, if not all, implementations fail to
support related BNFs anyway.

In the ideal world, I would support such simplifications, but it seems
to me that changing the existing protocol in such a way without also
changing the version number is not a good idea. There are already
several "subsubversions" of HTTP/1.1 that we have to deal with.

$0.02,

Alex.

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 16 Sep 2002 18:59:42 -0700

> Apache server and some proxies seem to handle "http/" just fine.

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 would think that errata is for fixing errors, not optimizing.

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 unless someone can explain why it is a necessary "feature".

....Roy

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 16 Sep 2002 22:35:49 -0600 (MDT)

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

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 17 Sep 2002 12:04:19 -0700

> developer does get our "RFC 2616 violations" reports.

The software that has been deployed since 1991 does not support
lowercase (or mixed case) "http" in the version string.  Using it
is not interoperable.  The specification defines what is interoperable,
not what might eventually be interoperable.

....Roy

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 17 Sep 2002 13:53:57 -0600 (MDT)

On Tue, 17 Sep 2002, Roy T. Fielding wrote:

> lowercase (or mixed case) "http" in the version string.  Using it is
> not interoperable.  The specification defines what is interoperable,

The specification defines what MUST/SHOULD/MAY be interoperable given
compliant implementation(s). Nothing else. Since the spec is written
before most implementations, the spec cannot predict what is actually
interoperable today, especially given that most (if not all) HTTP
implementations are not compliant!

More importantly, there are many things in RFC 2616 that are not
interoperable today, even on a MUST level. I can see two choices:

	- document interoperability problems
	  (there has been an effort to do that, like RFC 3143;
	  most of those problems are not true RFC errata, but
	  implementation bugs or areas that the RFC does not cover)

	- revise HTTP to remove whatever is not interoperable today
	  (your proposal belongs to this category, and there are
	  far more important things that do not interoperate; again,
	  this is not true RFC 2616 errata, but could lead to new
	  RFCs like "Streamlined HTTP" or "Slim HTTP" or, god forbid,
	  "HTTP/2.0"; is there enough demand to go in this direction?)

To summarize, I think that the change you propose makes perfect sense,
but I disagree that it is an errata. If the consensus is that changes
to reflect todays interoperability problems are appropriate, a lot
more similar changes should be done.

Thanks,

Alex.

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 17 Sep 2002 22:10:34 -0700

Perhaps there's some misunderstanding about the purpose of
the "errata" page. It doesn't really matter whether it's
a transcription error or a semantic change to the document,
we should document, in the HTTP "errata", ways in which the
spec is inconsistent with widely deployed HTTP implementations.

> more similar changes should be done.

It's reasonable to document these, and not to worry too much about
whether they are "changes" in intent or "changes" in specification
to match what was actually the original intent.

When the HTTP spec is revised, we can figure out how to
word the change list.

In general, unless there's some strong design reason to do otherwise,
we should change the spec to match what's implemented.

Larry