Am 03.06.2011, 15:16 Uhr, schrieb Eduard Pascual <herenva...@gmail.com>:
On Fri, Jun 3, 2011 at 2:23 PM, Dennis Joachimsthaler <den...@efjot.de>
wrote:
This grants the ability for any content provider to use an explicit
"Content-Disposition: inline" HTTP header to effectively block
"download links" from arbitrary sources.
True. Is it still so that some browsers ignore the "filename" part
of a content-disposition if an "inline" disposition is used?
Ok, I have never even thought about using the "filename" argument with
an explicit "inline" disposition. When I am in control of the headers,
I find it easier to "fix" the filename with 301/302 redirects, and
also have the bonus of some control about how that should be cached...
In short, I think that responding with a 2xx code _and_ attempting to
change what's essentially part of the URI through other means is a
contradiction, and thus a mistake on the best case, or some attempt to
fool the browser into doing something it shouldn't do on the worst
case.
Because of that, I'm ok with whatever way the browser decides to
handle the contradiction. You can read my position about
error-handling on my earlier post some minutes ago.
Personally, on the case I'm most concerned about ("data:" URIs used
for "Save log" and similar functionalities), there is never a "true"
disposition header; so my use cases do not push towards any of the
options. What I have just written is what I feel is the most
reasonable approach (the provider of a resource should have some
control over it above an arbitrary third party).
Data URIs would very well benefit from this attribute, in my opinion.
This would also cater to the canvas lovers. Downloading something
drawn on a canvas instantly? No problem! <a href="data:...."
disposition="attachment" filename="canvas.png">Download me!</a>
Yep, these are the cases I am actually concerned about. But on these
scenarios there is no HTTP header involved, so it doesn't matter (for
them) what takes precedence.
Yes, this was only an example which just came to my mind, nothing
special.
This is still one thing that has to be settled though.
a) How do we call the attribute?
Is there any reason to _not_ call it 'content-disposition'?
Ok, there is one: verbosity. But, personally, I have no issue with
some verbosity if it helps making things blatantly explicit.
So many years of browser vendors reverse-engineering the error
handling in competing products have convinced me that being explicit
is a good thing.
Yes, I was trying to refer to the verbosity. There's no html attributes
with dashes in them as far as I know, except for "data-", which are user-
defined. This would kind of break the convention a little. I could think
about having "contentdispo" or some shortname like this, it would fit
"better" to what we currently have in html.
b) Do we include the "filename" part directly into the attribute
or do we create a SECOND attribute just for this?
People have been posting several formats now. But I don't think we
actually have *agreed* upon one of those.
What's wrong with using the same format as HTTP? I am not too strongly
attached to that format, but I see no point in making things different
from what we already have. As a minor advantage, implementors can
reuse (or copy-paste) some few lines of parsing code instead of
writting them again, since they already parse the header when they get
it on an HTTP response.
Again, html convention: Currently html only has one "statement" in every
attribute, except for things like events (which is javascript) and style
(which is also ANOTHER language: css).
Seems cleaner to me if we stay to the "standard" and not change the syntax
"rules".
Please tell me if I missed anything here!
Regards,
Eduard Pascual
