Re: Comments on draft-ietf-httpbis-content-disp

Adam Barth wrote:
> Do you expect browser user agents to change their behavior w.r.t. the
> % character in filename parameter in Content-Disposition header
> fields?  I don't see an evidence that they will.

No, of course not.  Nor would I expect a package-management system to
start decoding % if the spec is changed based on what browsers get

> It's disingenuous to claim this document specifies the
> Content-Disposition header field when it ignores how that header
> field is processed by user agents used by hundreds of millions of
> users.

No, what's disingenuous is to tell all the folks who correctly followed
MIME syntax in their existing C-D implementations that they are in
error, based on an edge case where a *minority* of implementations
chose to disregard proper MIME syntax.  Granted browsers have hundreds
of millions of users, but that handwaving doesn't change the fact that
systems based on nonstandard %-handling are a statistical blip.

Just because browsers do this, doesn't mean they should, IOW +1 to
Bjoern's comment:

"Note in particular that we cannot assume, because something works in a
certain way in some browsers, that it is safe to require that; it may
very well be that the browsers that do something else cannot be up-
dated to match the behavior due to servers doing user agent sniffing,
in which case mandating the particular behavior was pointless and mis-

There's nothing preventing browser vendors from agreeing to %-decode or
even standardizing that *interpretation* of C-D.  The point is, that if
it's in another spec it has absolutely no bearing on how C-D is defined,
avoiding a break with backward compatibility for all user-agents.  That
"other spec" would only affect interpretation of C-D after parsing,
allowing that parsing to be compliant with the current draft, without
requiring the scope of HTTPbis to be changed to define non-MIME-
compliant header parsing.

> I don't see a connection between the ability to compute the requested
> file name from a Content-Disposition header field value and rendering
> content.

There is none.  But there are enough cases where it's true, to justify
a browser-conformance document.  Such a document can also choose to
specify anything else particular to browsers, such as deliberately-
borked C-D parsing which may break if required for HTTP-based package-
management systems, for example.

> Presumably the requested file name is part of the semantics of this
> header field value.  Shouldn't the specification define what that
> file name the header field requests?

No, it shouldn't, the user-agent has final say in what filename to use,
based on the filesystem the OS is using, which can't be known by the
sender, so the sender can only suggest a filename.  Which means that as-
written, the spec allows a component to decide to %-decode without it
being mandated that all user-agents ought to do so, because that's how
Microsoft did it...

> It sounds like you're advocating for resolution (2), which I think is
> fine.

No, I'm most definitely advocating the creation of a document specific
to the concerns of implementing HTTP on those user-agents which render
content, in a way that's interoperable between major browsers, and
keeping HTTP the way it's always been, which doesn't assume user-agent=
browser nor require a degree in computer science to be understood by
the lay developer.


Received on Monday, 1 November 2010 19:56:24 UTC