Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

MIME type sniffing bug (filename prioritized over content?) #4543

Open
jcaesar opened this issue Jan 3, 2018 · 1 comment
Open

MIME type sniffing bug (filename prioritized over content?) #4543

jcaesar opened this issue Jan 3, 2018 · 1 comment
Labels
status/in-progress In progress

Comments

@jcaesar
Copy link

jcaesar commented Jan 3, 2018 •
edited
Loading

Version information:

go-ipfs version: 0.4.13-3b16b74
Repo version: 6
System version: amd64/linux
Golang version: go1.9.2

(also happens with gateway.ipfs.io)

Type: Bug

Severity: Medium

Description:

In short:
For this URL ending in .png the http gateway wrongfully returns a Content-Type: image/png header.

Long story:
I was creating a little archive of clonk.de using wget -k --wait=3 -e robots=off -r http://clonk.de/.
Upon encountering the php files with search parameters, wget saved the files with a ? in the file name and converted the ? in the links to their hex escape %3F. This causes things like gallery.php?img=battle.png to have a file name that may make the file look like an image.

See also: #2164 and ipfs/notes#222
Stebalien added a commit that referenced this issue Jan 4, 2018
@Stebalien
don't sniff the filename to determine the content type
a63be70 
fixes #4543, may break other things

IMO, this is the best way to do this (for now, until we start manually storing
the content type along with the files). I'd rather not guess at all but we can
at least avoid guessing by filename.

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
@Stebalien Stebalien mentioned this issue Jan 4, 2018
Closed
@ghost ghost assigned Stebalien Jan 4, 2018
@ghost ghost added the status/in-progress In progress label Jan 4, 2018
@Stebalien
Copy link
Member

I've opened an RFC PR to discuss how to fix this: #4545.

@djdv djdv mentioned this issue Jan 27, 2018
Open
@Powersource Powersource mentioned this issue Aug 10, 2018
Closed
Stebalien added a commit that referenced this issue Oct 2, 2018
@Stebalien
don't sniff the filename to determine the content type
60d6b8d 
fixes #4543, may break other things

IMO, this is the best way to do this (for now, until we start manually storing
the content type along with the files). I'd rather not guess at all but we can
at least avoid guessing by filename.

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
@Stebalien Stebalien removed their assignment May 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
status/in-progress In progress
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[RFC] don't sniff the filename to determine the content type ipfs/kubo
2 participants
@Stebalien @jcaesar