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

On 8/11/2010 10:59 a.m., Adam Barth wrote:
> On Sun, Nov 7, 2010 at 12:50 PM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>> On 07.11.2010 21:32, Adam Barth wrote:
>>>> On 02.11.2010 03:56, Adam Barth wrote:
>>>>> ...
>>>>> The browser use case proceeds from the following premises.
>>>>>
>>>>> 1) Many servers send invalid messages to user agents.
>>>> No data was provided that this is indeed the case for C-D.
>>> No data was provided that this isn't the case.  Given that we see
>>> invalid message everywhere else, common sense tells us that we will
>>> see invalid messages here too.
>> In the absence of data telling me something else, I'll assume that servers
>> do sane things. I may be wrong. I just don't see why a server would *ever*
>> send two disposition types, given it's a waste of bytes and that it doesn't
>> cause the same thing to happen in different UAs.
> Why would a server ever send two Content-Types headers?  Why an HTML
> document ever mis-nest tags?  Why would a server ever send nonsense
> characters instead of an HTTP header?  All these things happen in
> practice because not everyone who operates servers is perfect.
>

I think we are getting way off base here.  There are probably at least 
trillions of ways in which UAs and Servers can send non-compliant messages.

I wouldn't propose modifying HTTP to cover those cases.  It doesn't make 
sense IMO for http to define a response for non-compliant behaviour 
except for it to be rejected.

Whether some software decides to second-guess intent and "recover" from 
such errors is in the end up to the developer of the software.  History 
has shown us such cures are often worse than the disease.

That's an area where security vulnerabilities have commonly crept in.  
It also provides zero incentive for broken UAs / servers / sites to 
clean up their act.  This then perpetuates the problems and makes it 
worse for everyone else for the inter-op reasons you mention.

If market share is your issue, maybe you should talk to PR about how you 
can spin breaking broken sites into a positive (which IMO it is 
generally - for security reasons).

In fact I thought we'd already thrashed out issues like this (specifying 
behaviour for behaviour that falls outside the spec) and decided we 
weren't doing that.

My 2c

Received on Sunday, 7 November 2010 23:02:55 UTC