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

On 8/11/2010 12:17 p.m., Adam Barth wrote:
> On Sun, Nov 7, 2010 at 3:02 PM, Adrien de Croy<adrien@qbik.com>  wrote:
>> 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.
> Thankfully defining how to handle all those trillion ways isn't
> actually that difficult.
>
>> 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.
> Rejecting invalid message is not implementable by browser user agents.
>   If we'd like our specs to be implemented, that's not an option.

the day the first major browser chooses to do it one of 2 things will 
happen.  If they do it properly that is.  If they don't they are hosed.

If they post a big red page and say

"this website responded in an improper manner, which may have security 
implications.  We are protecting you from this..." or words to that 
effect, then who will the user blame?  The browser or the website?

Then users are more likely to push the website to be fixed, and in any 
case the website wants to be seen, and not be seen as a potential 
security risk.  In fact Google could do this unilaterally with its 
existing infrastructure (the one that tells us a page is unsafe to 
visit).  Then the other browser vendors can breathe a sigh of relief and 
undo all the hacks they were forced (so they believed) to put in to 
compete with IE.

>> 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.
> You and I appear to have a different interpretation of history.

Funny, I thought you shared that view, and that's why you wrote your I-D 
on content sniffing.


>> 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.
> We disagree about whether or not that is a problem.
>

see above.

Regards

Adrien

>> 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).
> This isn't really even worth responding to.
>
>> 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.
> It appears not everyone shares that opinion.
>
> Adam

Received on Sunday, 7 November 2010 23:28:09 UTC