On 5/8/13 10:45 AM, Gordon P. Hemsley wrote:
I still think @download takes priority.
The Content-Disposition header says, "Nevermind what filename the URL
shows; this is really file B.txt."
The @download attribute says, "Nevermind what filename this link would
normally be; let's just consider it A.txt."
OK, that's at least a reasonable argument for the behavior. ;)
OK, technically, the way I phrased it, yes. But what I meant was that
it rolls a bunch of steps into one, telling the browser that the link
should be downloaded and named per suggestion.
Yes, but the key is _who_ is making the suggestion and why.
That seems like quite a sophisticated attack that relies on a lot of
things falling into place all at once.
Uh... yes. Like most browser exploits.
Then I think it is the responsibility of the UA to sniff the file and
protect the user from such attempts to mislead.
This is not trivial, since sniffing can easily fail on files that are
both HTML and png or both HTML and exe at the same time. There's a good
bit of research on things like this.
There is a price to freedom, as they say. We shouldn't let a few
rotten apples spoil the whole bunch.
If it's going to open users to exploits.... we do it all the time.
I'm not sure I have the resources to do extensive real-world testing
of this (and that documentation suggests it has been superseded in
more modern OSes), but I don't think it would be unreasonable for the
UA to override or augment the filename suggested by the @download
attribute it if determines that it would not be in the best interest
of the user to use the suggested filename unchanged.
Phrased that way, using the Content-Disposition filename is a perfectly
valid "override if not in the best interest of the user" behavior, fwiw.
-Boris
