[pmwiki-users] The Content-Disposition Header Field

[Monty]

> Date: Fri, 15 Apr 2005 14:56:21 -0500
> From: "Patrick R. Michaud" <pmichaud at pobox.com>
> Subject: Re: [pmwiki-users] pmwiki-2.0.beta31 released
> Content-Type: text/plain; charset=us-ascii
> 
> By default when PmWiki generates "Attach:" links, it creates them as 
> "direct" links into the webserver directory.  For example, in the 
> Cookbook the markup "Attach:gemini.zip" is converted to a link to 
> http://www.pmwiki.org/pmwiki/uploads/Cookbook/gemini.zip.
> Note that when followed this link will completely bypass the pmwiki.php
> script, and act as though you were accessing any "normal" file
> on the webserver.
> 
> This has some advantages and disadvantages.  The biggest advantage is 
> that it's fast, in that the webserver doesn't have to execute a PHP
> script in order to return the appropriate file to the browser.  The
> webserver can also take care of determining the appropriate Content-Type
> for the file.
> 
> However, a big disadvantage is that all attachments are publicly 
> accessible as long as someone knows the URL.  In addition, there are
> some environments (examples include IIS and sourceforge.net) where the
> webserver disallows direct access to files that have been created
> by a PHP script.
> 
> As a result, beta31 now offers an ?action=download option, which can be used 
> to retrieve a page's attachment.  For example, with $EnableDirectDownload 
> set to zero, PmWiki will convert the "Attach:gemini.zip" markup into 
> http://www.pmwiki.org/wiki/Cookbook/GeminiSkin?action=download&upname=gemini.zip
> 
> This provides some important features:
>   - it allows PmWiki to use site/group/page permissions to control
>     access to attachments
>   - it means the uploads/ directory no longer needs to be web accessible
>     and can be anywhere in the filesystem
>   - the file's Content-Type and semantics can be controlled by PmWiki
>     which may be easier to configure (e.g., it makes it easier for .php
>     attachments to be downloaded instead of executed on the server)
> Of course, the downside of this is that accessing an attachment
> a somewhat heavier load on the server, since it now involves 
> running a PHP script and determining the page's permissions before
> the file can be transmitted.
> 
> Still, for sites that want to use PmWiki's authorization system to
> restrict access to attachments, or that are on webservers that disallow
> accessing the attachments directly, this is an incredibly useful feature
> and the trade-offs in performance isn't important.
> 
> Does that help?
> 
> Pm
> 

Patrick-

Is this code RFC 2183 (Communicating Presentation Information in 
Internet Messages: The Content-Disposition Header Field) compliant?
c.f. http://www.faqs.org/rfcs/rfc2183.html

-Monty