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

Re: TICKET 259: 'treat as invalid' not defined

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 08 Nov 2010 09:58:11 +0100
Message-ID: <4CD7BBA3.6090204@gmx.de>
To: Adam Barth <ietf@adambarth.com>
CC: httpbis <ietf-http-wg@w3.org>
On 07.11.2010 22:59, Adam Barth wrote:
> ...
> Why would a server ever send two Content-Types headers?  Why an HTML

Because the code is setting it twice, maybe in different components.

> document ever mis-nest tags?  Why would a server ever send nonsense

Because UAs accept it, and authors have almost zero reason to test it?

> characters instead of an HTTP header?  All these things happen in
> practice because not everyone who operates servers is perfect.
> ...


But it doesn't happen for all areas with the same frequency. Thus I 
think you conclusion that the answer to this must be the same across all 
layers is wrong.

>>> ...
>>>> As my tests show, there is no "same" behavior right now. It's totally not
>>>> clear that this is a problem in practice.
>>> It is a problem in practice.
>> Why?
> Lack of interoperability usually a problem.  Here's an example that
> has been causing me a lot of pain recently.  Consider this syntax in
> an HTML document:
> <script src="..." />

I was talking about Content-Disposition specifically.

> ...
>> We currently have a warning. I would *love* to tell server implementors
>> about a way to workaround this problem, but there isn't (for released
>> versions of Chrome and IE). So what do you propose to tell senders? "%xx" is
>> not allowed in filenames?
> Yes, just like we tell them that U+2665 isn't allowed.

The inability to express a literal %xx sequence in a filename IMHO would 
be very strange. Right now the restriction is there de factor, but so is 
the restriction to ISO-8859-1. This spec tries to improve that.

Best regards, Julian
Received on Monday, 8 November 2010 08:58:56 UTC

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