[pmwiki-users] The Content-Disposition Header Field
pmwiki at ioioi.us
Mon Apr 18 11:00:06 CDT 2005
> 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
> 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
> 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?
Is this code RFC 2183 (Communicating Presentation Information in
Internet Messages: The Content-Disposition Header Field) compliant?
More information about the pmwiki-users