Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Set filename in Content-Disposition if filename=x is passed in URI query #4177
@lgierth Is this waiting on any more changes? Is there a need for a branch based on MIME type? ('inline' for application/pdf, and 'attachment' for everything else) or is 'inline' ok to pass for all MIME types?
Without this feature linking to files is a big problem (I often specifically do not want wrapping directories, but a direct link). Luckily, for
Looks like it just dropped through the cracks.
This PR doesn't appear to do any content sniffing, it just sets the appropriate file name.
Aug 21, 2018
7 checks passed
Thank you for picking this up!
On Mon, Aug 20, 2018 at 03:05:29PM -0700, Steven Allen wrote: > Is there a need for a branch based on MIME type? ('inline' for application/pdf, and 'attachment' for everything else) or is 'inline' ok to pass for all MIME types? This PR doesn't appear to do any content sniffing, it just sets the appropriate file name.
The current PR does not do any discrimination based on MIME type, but it does choose one other parameter besides the filename: for all MIME types it sets the 'inline' parameter, as opposed to the 'attachement' parameter. The meaning of this parameter is documented in ContentDisposition docs, but it's self-explanatory, 'inline' tells the viewer to render the content within the same window (e.g. the browser pdf-viwer plugin for application/pdf), vs 'attachment' tells the viewer to show a 'Save As...' dialog. Browsers probably ignore 'inline' (i.e. treat it as 'attachment') in case no viewer is available for that type, (e.g. if you send 'inline, application/zip' the browser will probably open Save As dialog), so probably it is ok to send 'inline' for all types. Do you think this could cause a problem with any browser or other client?