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

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.

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

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

> 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:18:35 UTC