Set filename in Content-Disposition if filename=x is passed in URI query #4177
Conversation
core/corehttp/gateway_handler.go
Outdated
| @@ -132,7 +133,7 @@ func (i *gatewayHandler) optionsHandler(w http.ResponseWriter, r *http.Request) | |||
| } | |||
|
|
|||
| func (i *gatewayHandler) getOrHeadHandler(ctx context.Context, w http.ResponseWriter, r *http.Request) { | |||
|
|
|||
| log.Errorf("see me?") | |||
core/corehttp/gateway_handler.go
Outdated
| @@ -6,6 +6,7 @@ import ( | |||
| "fmt" | |||
| "io" | |||
| "net/http" | |||
| url "net/url" | |||
There was a problem hiding this comment.
You can just do "net/url" here, the import name will be the same
Voker57
force-pushed
the
feat/gw-filename-option
branch
from
7462e4c
to
aa8a81b
Compare
Voker57
force-pushed
the
feat/gw-filename-option
branch
from
aa8a81b
to
e83d664
Compare
Voker57
force-pushed
the
feat/gw-filename-option
branch
from
e83d664
to
4d6b914
Compare
|
It works for |
|
That's out of scope of this PR: I just want files that are saved from link to be named properly. |
|
@Voker57 sounds good, I wanted to suggest a |
Voker57
force-pushed
the
feat/gw-filename-option
branch
from
4d6b914
to
8fef8a3
Compare
License: MIT Signed-off-by: Iaroslav Gridin <voker57@gmail.com>
Voker57
force-pushed
the
feat/gw-filename-option
branch
from
8fef8a3
to
7b34b7f
Compare
|
@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. |
|
I've checked and this does not trigger #4025. |
|
@lgierth. I'd like to merge this. Any objections? |
|
I've added some documentation here: #5393 |
|
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?
|
|
According to the docs, "inline" is the default value so this shouldn't cause a problem. We should probably also add a (thanks for bringing this to our attention, by the way) |
This implements 'attachment' mode triggered then ?filename parameter is accompanied with &download=true When Content-Disposition: attachment is detected by a modern browser it will skip rendering and immediately open the "save as" dialog, making this useful feature for using IPFS gateway as target of "Download" links on various websites. Parameter name was suggested in: #4177 (comment)
Set filename in Content-Disposition if filename=x is passed in URI query This commit was moved from ipfs/kubo@fcc96a3
This implements 'attachment' mode triggered then ?filename parameter is accompanied with &download=true When Content-Disposition: attachment is detected by a modern browser it will skip rendering and immediately open the "save as" dialog, making this useful feature for using IPFS gateway as target of "Download" links on various websites. Parameter name was suggested in: ipfs/kubo#4177 (comment) This commit was moved from ipfs/kubo@fd01acd
Helps with referring to hashes by specific filename, eliminated unixfs node need for that
Example: http://ipfs.io/ipfs/Qmfoobar -- downloads Qmfoobar.zip (if mime was detected by first block)
http://ipfs.io/ipfs/Qmfoobar?filename=stuff.zip -- downloads stuff.zip