NYCPHP Meetup

[Dan Cech]

Chris Shiflett wrote:
> --- Dan Cech <dcech at phpwerx.net> wrote:
> 
>>$attach = array(
>>   'filename' => 'myfile.pdf',
>>   'mimetype' => 'application/pdf',
>>   'content'  => 'pdf here'
>>);
>>
>>header('Content-Disposition: attachment; filename='.
>>$attach['filename']);
>>header('Content-length: '. strlen($attach['content']));
>>header('Content-type: '. $attach['mimetype']);
>>echo $attach['content'];
>>exit;
> 
> 
> Note the case of Content-Length and Content-Type. This doesn't affect
> implementation, but we may as well be perfectionists. :-)

Hehe, I was wondering how long it would be before someone called me on 
that, see my previous mail to the list... That's what I get for posting 
before I check the relevant RFC.

> I think using an array makes the syntax a bit cumbersome, but that's just
> personal preference.
> 
>>The Content-Disposition header tells the browser to open the
>>download dialog, and lets it know the correct filename/extension.
> 
> As shown, yes. You can specify the inline attribute to do the opposite,
> basically making the resource an embedded one. Dan clearly knows this - I
> only mention this to make sure our wording isn't misleading. I know a lot
> of people who think the header() function is for redirecting, for a
> similar reason.
> 
>>The Content-type header lets the browser correctly display an
>>indication of the file type to the user (PDF,XLS,EXE etc). In
>>most browsers it will also influence the default action (open vs
>>download).
> 
> I have read where developers intentionally set an unknown mime type when
> they want to force a download. Does anyone know whether this is justified?
> The argument I've seen is that when the browser has a default action
> specified for the given mime type, the attachment attribute of
> Content-Disposition is ignored, and the resource is displayed inline
> instead.

The most common trick seems to be to specify the mime-type as 
application/force-download or application/x-download, though I haven't 
been able to find any specification relating to these mime-types.

This is possible, though it seems a nasty hack because the download 
dialog for the user would most likely display an 'unknown file type' and 
would probably trigger such things as the WinXP 'firewall', etc.

The idea I guess would be to work around a user who has told their 
browser to always open a particular kind of file without prompting 
(usually such things as .pdf,.xls or .doc files), but in doing so you 
are really exceeding the limits of the specification, and are really at 
the mercy of implementation quirks.

According to the (RFC2183) spec you can use an unknown 
Content-Disposition, as the spec states it should be treated as 
Content-Disposition: attachment.  However I haven't experimented with 
this myself.

Dan

> Chris