W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

Re: what does "unrecognized header fields" mean?

From: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
Date: Tue, 26 May 98 13:48:21 EDT
Message-Id: <199805261752.AA13375@reston.vmd.sterling.com>
To: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/138
Dave Kristol <dmk@research.bell-labs.com> writes:

>The question I have is, what does "unrecognized" mean?  Does it just
>mean a header whose name is unfamiliar,

That's certainly the implication.  There are 12 uses of the term in the
-03 level of HTTP 1.1, and they all focus on "unrecognized" as "not
known to the implementation" (as opposed to "not properly constructed").

>                                        or does it also mean a
>recognized header for which the value is in some way invalid (such as
>my example above)?  I realize that "be liberal in what you accept" is
>on my side, here, but it's not clear that the *letter* of the
>specification is also on my side.

The letter appears to be against you in two ways.  In the case of
handling "unrecognized" headers, "urecognized" appears to mean "not
known to the implementation").  Section 3.7.2 uses the term to clearly
mean "a MIME type that this implementation does not know of", as the
requirement is to treat unrecognized subtypes of MULTIPART as
MULTIPART/MIXED.  Sections 4.5, 5.3, and 6.2 discuss general, request
and, response header fields by name and require an implementation to
treat unrecognized headers as entity-headers.  Section 5.1.1 discusses
handling of unrecognized methods in a context that implies it to mean
unknown.  Likewise section 6.1.1 when discussing status codes.  Section
7.1, upon which your argument would hang, implcitly defines
"unrecognized" in terms of the BNF for <extension-header>, when it says:

   "The extension-header mechanism allows additional entity-header
   fields to be defined without changing the protocol, but these
   fields cannot be assumed to be recognizable by the recipient.
   Unrecognized header fields SHOULD be ignored by the recipient
   and MUST be forwarded by transparent proxies."

Section 14.9.6 makes much the same implication.

The second point to make is that an empty REFERER: header is illegal.
The BNF in section 14.36 reads:

   "Referer        = "Referer" ":" ( absoluteURI | relativeURI )"

There is a required value.  Surely the RFC can't make a normative
statement expecting a compliant implementation to ignore mal-formed
headers - that way would lie madness and miscommunication.

Ross Patterson
VM Software Division
Sterling Software, Inc.
Received on Tuesday, 26 May 1998 10:50:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC