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

Re: Working Group Last Call: draft-ietf-httpbis-content-disp-02

From: Adam Barth <w3c@adambarth.com>
Date: Sat, 2 Oct 2010 17:26:06 -0700
Message-ID: <AANLkTimqfS0Dt2BP0gNEYVg+Lnp1XAGKFek1rk2AKtoG@mail.gmail.com>
To: "Eric J. Bowman" <eric@bisonsystems.net>
Cc: Julian Reschke <julian.reschke@gmx.de>, Bjoern Hoehrmann <derhoermi@gmx.net>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
As far as I can tell, your entire message is beating up on a strawman.
 I haven't proposed any of the things you're shooting down.

Adam


On Sat, Oct 2, 2010 at 5:11 PM, Eric J. Bowman <eric@bisonsystems.net> wrote:
> Adam Barth wrote:
>>
>> Given that browsers are going to interpret nonconformant syntax, I'd
>> rather live in a world in which they all did it the same way.  That
>> world is more predictable, which is better for security, and easier
>> for new entrants to the market because those new entrants don't need
>> to reverse engineer existing implementations.  Fewer barriers to entry
>> means more competition, which means users get a better browser
>> product.
>>
>
> The position is well-known, but that is not to say the premise is
> agreed to by the majority, or any constituency beyond browser vendors.
> I disagree entirely with the notion that it's somehow better for
> security to change the must-ignore nature of Web architecture to one of
> must-process...
>
> http://blogs.wsj.com/digits/2010/09/24/what-caused-facebooks-worst-outage-in-four-years/
>
> ...given that this sort of error-prevention-correction approach leads to
> just such a cascading database failure requiring the entire site to be
> taken offline and brought back up in a different configuration, instead
> of simply allowing 500 errors to occur.  That's the only way submitted
> code will ever be corrected without opening a big gaping security/
> stability hole by resorting to error correction.  I don't believe in
> specifying any sort of error correction, because those hidden security/
> stability implications are always lurking and aren't outweighed by the
> need for user convenience.
>
> If the spec were to define how to parse a string with two filenames,
> it would lead to folks thinking it's conformant to send a string with
> two filenames.  Or to transcode the string to have only one filename.
> The last thing that the resulting confusion needs, is standardization.
> The only thing which requires standardization, is how to do it properly.
>
>>
>> Insulting an important constituency is unlikely to generate consensus
>> by win that constituency over to your point of view.
>>
>
> Speaking as a long-time Web Developer, I'm appalled by the dismissive
> and insulting attitude taken by the constituency dictating HTML 5 as
> pertains to the standards that myself and those like me are perfectly
> capable of understanding, by declaring repeatedly that we're a bunch of
> morons who can't understand resource/representation or anything else
> the vendors are hell-bent on changing, as justification for said
> changes ignoring those well-understood standards.
>
> Which motivates me to participate in this thread, because I don't want
> that vendor-centric approach to pollute HTTPbis, rendering the spec so
> large and unwieldy that only browser vendors could ever hope to
> understand its meaning, in terms of what they've implemented.  A big,
> emphatic -1 to the notion that HTTPbis should follow HTML 5 down the
> road of standardizing error correction behavior for user agents, for
> C-D or anything else.
>
> You have your rationales like "more secure," etc. but I have never
> bought into the arguments behind them, as they defy my experience, most
> recently confirmed by Facebook the day before yesterday -- error
> correction is an inherent security problem and has no business being
> written into HTTP.
>
> -Eric
>
Received on Sunday, 3 October 2010 00:32:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:27 GMT