Re: treating invalid parameters in Content-Disposition

Adam Barth wrote:
> > The concern about driving customers away is an *opinion* and not a
> > fact, and even if true, the consequences of silent recovery in
> > browsers lead to the much larger problem of gaping
> > security/stability holes.  Willful violations of Web architecture
> > can't be called secure in the name of user convenience, nor are
> > errors resulting from not following standards to be considered "bad
> > behavior" or the "wrong thing" -- they're critical to the nature of
> > _networked_ software architecture on the open Internet. Browser
> > vendors' desire to hide errors leads to a more fragile Web, i.e.
> > the opposite of the robustness principle.
> People have been making that argument for years, and still the popular
> user agent implementor follow their incentives to maximize
> compatibility.  Presumably the ones that listened to this advice
> failed to become popular.  You're not going to change their behavior
> without changing the incentives.

Just as you're not going to change how RFCs are drafted by calling the
result "correct architecture" that needs to be specified by HTTP.  The
concerns of browser vendors aren't the only concerns around HTTP, which
can't fundamentally oppose the nature of _networked_ software
architecture based on the *assumption* that the result will be an
improved Web -- when you haven't offered any proof that it wouldn't
cause the whole thing to come crashing down into a smoking non-
interoperable heap by allowing all unspecified syntax instead of
restricting to what's defined by MIME.

> > You can't tell me that you've thought of and accounted for every
> > possible consequence of abandoning standard MIME syntax for C-D in
> > favor of allowing %-encoding.  Whereas I'm quite comfortable with
> > the notion that any interoperability issues with conformant syntax
> > lurking out there would've been found by now.  It defies logic to
> > claim that it's easier for a new entrant to the browser market to
> > implement different parsers for different headers instead of
> > following MIME syntax defined for *all* headers.
> ... and yet that's exactly what the newest successful entrant into the
> market has done.

Hardly a convincing rebuttal to my point that having separate parsers
for separate headers raises the bar on any new entrant to the market --
"Yes, they do, but this didn't stop Google."  I forgot how limited are
Google's resources...

> I encourage you to bring a browser to market that behaves as you
> suggest.  I suspect you'll have great difficulty acquiring users if
> the folks who try your browser experience an incompatible web site
> every day or if they can't use NewEgg.

I have no desire to enter the browser market, which doesn't mean I
don't develop HTTP user agents for other purposes.  I don't care how
such user agents interpret NewEgg, I only care how they interoperate
with the standards as written, and I certainly care that they don't
engage in silent error correction when encountering nonstandardized
syntax because "so does Google and Microsoft."

It's ludicrous to suggest that I write separate parsers for separate
headers because HTTP standardized syntax I never would have suspected
to be valid based on 17 years of experience.  If Google, Apple and
Microsoft want to increase time-to-market and complexity to solve
problems I'll never face, fine by me, but don't impose their solutions
back on the rest of the world by standardizing aberrant behavior.


Received on Sunday, 3 October 2010 21:12:14 UTC