[tahoe-dev] help: how should you tell a web browser what name to use for a file?

Nathan nejucomo at gmail.com
Fri May 9 18:14:59 PDT 2008


On Fri, May 9, 2008 at 5:42 PM, Ben Hyde <bhyde at pobox.com> wrote:
...

> On May 9, 2008, at 2:51 PM, zooko wrote:
...

>> We could use two slashes instead of one to make them visually
>> different from "name of child within its parent" URLs:
>>
>> http://tahoebs1.allmydata.com:8123/named/URI%3ACHK%
>> 3Awaqatup4yk7dyoosuyaux6vwzu%
>> 3Alzoa4c2phsp3x7ws47bofsbihjm5avxqo35qrqscgqvtwrjotyra%3A3%3A10%
>> 3A313227//zookostiddlerdemo.html
>
> ... I'd advise against the double slash hack; since
> I've seen a lot of code in my day that reduces multiple slashes to
> single
> ones; as multiples are so easily created in shell scripts; e.g. $dir/
> $name

I strongly second this.  There are quite a few different rfcs on urls,
but the original explicitly forbids this construct in the grammar.

One means of telling the browser to name a download is specified in HTTP/1.1:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1

If this appears to work in cross-browser tests, then keeping the
existing "?filename=" query parameter in the GET URI and reflecting
that into the content-disposition header is the best balance between a
consistent wapi ui and browser behavior.  (This assumes everyone
respects the 1.1 standard well...)


An aside on security:
There are potential security issues with reflecting request parameters
into http headers.  Specifically, you need to disallow line breaks
(which allow a malicious link designer to do weird things with the
response headers).  There are probably more I'm not aware of.
Additionally, exposing file naming to a link malicious link creator is
an attack surface against the downloader's fs api, but hopefully
enough apps do this that browser implementors handle it well.  (What
if filename == ".." or "\\ev.il.ip.addr\foo" ?)


An aside on QA:
If you don't already have automated cross browser tests, it might be
worthwhile (although painful) to set them up.  As you encounter more
browser-integration issues, it'd be nice to keep your test coverage
thorough.  I don't have much experience with this, but I've seen
Selenium used in various large web application test environments:
http://selenium.openqa.org/


>
>  - ben
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
>


Nathan


More information about the tahoe-dev mailing list