W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

Re: NEW ISSUE: repeating non-list-type-headers

From: David Morris <dwm@xpasc.com>
Date: Tue, 20 Nov 2007 08:53:22 -0800 (PST)
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.33.0711200832330.28406-100000@egate.xpasc.com>

On Tue, 20 Nov 2007, Julian Reschke wrote:

> That's all true, but it doesn't answer the question of what a recipient
> should do with something like:
>     Content-Type: text/html; charset=ISO-8859-1
>     Content-Type: text/plain
> (see <http://lists.w3.org/Archives/Public/public-html/2007Nov/0271.html>).
> ...or even worse, with conflicting Content-Length headers....

In the end, quite simple ... if the recipient doesn't understand the
message, it should report an error and reject the message. As I recall,
in the original 1.1 time frame, there was a discussion of creating a
mechanism where by user agents could report errors to origin servers and
this was rejected, in part at least, because of concerns re. DOS attacks.

There really isn't that much point in folding headers and in fact this
possiblity makes parsing more difficult. What a revised spec should do is
focus on interoperability and describe requirements which insure

a. The order of the values of repeated header must be preserved
b. The order of repeated headers known to have list values MAY be
   folded OR unfolded at the convenience of the processing entity.
c. The Content-type example is no more confusing than receiving a
   flash movie (.flv type) coded as text/plain. Processing entities
   must write code which will survive the wild west. The most we should
   do is list alternatives and recommend that any individual
   implementation be consistent. Take the first, take the last, use as
   hints in analysis of the actual entity... Report as an error.

Where it doesn't matter, the specification should not impose restrictions
since there is no power of enforcement.

Dave Morris
Received on Tuesday, 20 November 2007 16:53:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC