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

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:12:06 UTC