2

I know that we should replace forwards slashes and for example explode the path and use the last element of the array as filename.

But why is the fordward slash converted to a hyphen / dash when using

header('Content-Disposition: attachment; filename="'.$local_file.'"');

when $local_file is something like /file

the downloaded file has the filename -file

Is this behaviour described somewhere?

The rfc paper does not mention this, or does it? http://www.faqs.org/rfcs/rfc2183.html

  • 3
    Because header should have filename, and not path. Thats why `/` is invalid in filename. – Glavić Nov 30 '14 at 16:14
  • [Check this Q&A](http://stackoverflow.com/questions/93551/how-to-encode-the-filename-parameter-of-content-disposition-header-in-http) – anubhava Nov 30 '14 at 16:20
  • is it good/secure to use / in the filename? I think not because every client might handle this differently. –  Nov 30 '14 at 16:23
  • The relevant RFC is http://greenbytes.de/tech/webdav/rfc6266.html – Julian Reschke Nov 30 '14 at 20:52

1 Answers1

2

This is client specific. Most browsers would just drop any path/ prefixes. But transcoding forward slashes would be just as sound.

It's alluded to in RFC2616, http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html, section 19.5.1

The receiving user agent SHOULD NOT respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply to HTTP implementations at this time. The filename SHOULD be treated as a terminal component only.
Network Working Group, R. Fielding et al, (c) The Internet Society (1999)

The rationale of course is, that HTTP payloads should not be extracted to any predefined path for security reasons.

mario
  • 144,265
  • 20
  • 237
  • 291
  • ok, makes sense, but as it is client-specidif, isn't it a bit inaccurate as it can be different from cleint to client? shouldn't we replace the slash with a desired character like underscore or a dash/hyphen directly? –  Nov 30 '14 at 16:22
  • 1
    The most recent and specific definition is in [rfc6266](https://tools.ietf.org/html/rfc6266#page-5) btw, which even recommends character replacements. It does not prescribe how and when, as there are differences from platform to platform what constitutes special characters. – mario Nov 30 '14 at 16:23
  • so it is definitely better to replace these slashes directly in PHP instead of relying on the client and platform. Okay, thanks for the link to the rfc –  Nov 30 '14 at 16:26
  • RFC 2616 is obsolete. What's relevant for Content-Disposition is http://greenbytes.de/tech/webdav/rfc6266.html – Julian Reschke Nov 30 '14 at 20:52