[whatwg] "Content-Disposition" property for <a> tags

On Fri, Jun 3, 2011 at 3:24 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 6/3/11 9:16 AM, Eduard Pascual wrote:
>>
>> 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
>
> That doesn't work if the data is dynamically generated.

As a matter of fact, it does. It takes some work, and quite a bit of
creativity with ModRewrite or similar tools, but is perfectly
achievable. The key is to do the redirection _before_ starting to
generate the data, and to keep enough information on the final URI to
recover the parameters once the script actually gets into
data-generation.

>
>> 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
>
> The "filename to save the data as" is not "part of the URI".
>
> Think a URI like this:
>
> ?http://mysite.org/generate_progress_report.php?quarter=Q12010
Wouldn't that default (in the absence of a Content-disposition) to
"generate_progress_report.php" as the filename? That's what I meant by
"part of the URI".

> When saving, it would be good to use something like "Progress report of Q1
> 2010" as the filename. ?But that's not "part of the URI" in any sense.
It would, if the author wanted it to be. Turning that URI into
something like "http://mysite.org/ProgressReport_Q1_2010", for example
(that's what I'd probably do in that scenario) is quite simple to
achieve. A literal URI like http://mysite.org/Progress report of Q1
2010" would take some extra work to get working right, but is still
doable.

After all, if the author cares about having a reasonable filename, why
wouldn't they care about having a descriptive URI? The filename option
on Content-Disposition headers is just a partial solution to a problem
for which a more powerful solution already exists.

> Note that some browsers will do weird parsing of the query params to attempt
> to extract a "useful filename". ?That seems strictly worse than just using
> Content-Disposition.
Not on my sites :P My URIs are a "useful filename" by themselves.

>> 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.
>
> I strongly disagree. ?I think browsers that use the Content-Disposition
> filename for "attachment" but not "inline" are just buggy and should be
> fixed.
Ok, maybe I used a too harsh wording for that, but for all the
situations I can think of where a filename argument would make sense I
can achieve a better result through URI beautification. I still think
it's a mistake to try to fix a "filename" but not fix the URI. The
"attempt to fool the browser" part was more about evil sites serving
files with names like "hotnudepic.jpg.exe" (I have seen real sites in
the past doing thinks like that, and even worse).
In any case, note that my comment was about what *authors* should do.
Browsers will attempt to do whatever is good for the users, and I'm ok
with that.

> Of course it sounds like your position is that they should not use the
> filename for "attachment" either... (in which case you disagree not only
> with me, but with most of the web).
Actually, my position is more like "I don't care what the browser does
with this because I have no need to use it". Honestly, I hadn't looked
into the filename option of that header until the discussions about
adding this feature to links and/or data: URIs started. data: URIs, by
their very own nature, are not suited for beautification. And even if
this feature gets implemented, the filename part doesn't concern me
too much, since it's just a mere convenience, and the user always has
the final say on what the file name will be (even if a browser didn't
allow changing that, the user could rename the file afterwards).

Regards,
Eduard Pascual

Received on Friday, 3 June 2011 07:39:08 UTC