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