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

Re: treating invalid parameters in Content-Disposition

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Sun, 3 Oct 2010 14:43:23 -0600
To: Adam Barth <w3c@adambarth.com>
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>
Message-Id: <20101003144323.9ee52480.eric@bisonsystems.net>
Adam Barth wrote:
>
> > I understand what you mean perfectly well.  I still don't see the
> > relevance of that dichotomy to HTTP.  Why should C-D generation be
> > defined in terms of handling syntax that was never specified?
> 
> No one is proposing that.
> 

Well, yes, you're suggesting that the conformant syntax include %-
encoding, which was never defined as allowable syntax to begin with.
It isn't an error in the C-D draft to exclude syntax that's never been
specified, by defining a subset of syntax that has been specified,
which treats % as a literal character.

>
> >  Why should such implementation details even be included in HTTP?
> 
> No one is proposing that.
> 

I'm still responding to you original claim, "This document appears to
be insufficiently precise for user agents to implement Content-
Disposition...  The grammar will fail to parse a large number of
Content-Disposition headers user agents receive on the public Internet,
etc..."  The only thing you've said is that in lieu of such details,
the draft should include language stating that it isn't useful to user
agents.  I'm against both.

> 
> 1) The browser does the wrong thing on 1% of all page views.  That
> means users will be seeing the browser do wrong things on a daily, or
> at least weekly, basis (based on statistics about the distribution of
> number of page views).  That more than enough to drive potential
> customers away.
> 

That's where you and I are going to have serious disagreements on the
nature of _networked_ software architecture.  The Web isn't a closed
system.  Errors need to be reported to users, or rather, developers.
Once the producer of content sees an error instead of a result, the
error may be fixed.  Your perspective is what leads to total site
failure to avoid reporting a 500 error to the user, i.e. Facebook
DDoS'ing itself the other day.  That's "correct" behavior?  I'd rather
my website visitors see error messages (or rather, that I see them and
correct them first) than break how the Web achieves interoperability at
Internet scale (by allowing errors to happen, primarily 404).

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.

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.

-Eric
Received on Sunday, 3 October 2010 20:44:29 GMT

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