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

IPNS dnslink tld interpreted as file ending, which affects assumed content-type #5369

Closed
Powersource opened this issue Aug 10, 2018 · 2 comments · Fixed by #5564
Closed

IPNS dnslink tld interpreted as file ending, which affects assumed content-type #5369

Powersource opened this issue Aug 10, 2018 · 2 comments · Fixed by #5564
Assignees
@Stebalien
Labels
kind/bug A bug in existing code (including security flaws)

Comments

@Powersource
Copy link

Powersource commented Aug 10, 2018 •
edited
Loading

Type:

Bug

Description:

I made a dns txt record for my site that looks like this
"dnslink=/ipfs/QmYgdZ7Rhk2PRawzGu1FBHQSRsMaVMCJUF7NcbY6wVr4WC".
When you visit https://ipfs.io/ipns/jacob-karlsson.com you get the content-type application/x-msdos-program which is not expected. However, when I visit https://ipfs.io/ipfs/QmYgdZ7Rhk2PRawzGu1FBHQSRsMaVMCJUF7NcbY6wVr4WC I get the expected image/gif. This happens in both Firefox and Chrome for me, but someone in irc reported it working for them (the bug started happening for them too after they disabled a beta version ipfs companion).

My guess is that this is a combination of #4543, and ipfs.io having a mime-type definition file somewhere that includes this https://whatis.techtarget.com/fileformat/COM-Command-file-program (I tried to find an actual example of a file like this but didn't manage). I.e. the gateway thinks my website's url is a filename.
@Powersource Powersource changed the title IPNS dnslink tld interpreted as file ending IPNS dnslink tld interpreted as file ending, which affects assumed content-type Aug 10, 2018
@Stebalien Stebalien added the kind/bug A bug in existing code (including security flaws) label Aug 10, 2018
@daviddias daviddias added the status/ready Ready to be worked label Aug 12, 2018
@eingenito
Copy link
Contributor

@Stebalien following #4543 and #4545 is this issue blocked on that work? Should I move it out of ready?

@eingenito eingenito mentioned this issue Oct 2, 2018
Closed
@Stebalien
Copy link
Member

Yeah, this is the same as #4543 and I still believe #4545 is the correct solution. Let's see if we can push that forwards. Thanks for bringing this up.

Stebalien added a commit that referenced this issue Oct 4, 2018
@Stebalien
don't use the domain name as a filename in /ipns/a.com
90f37d4 
fixes #5369

License: MIT
Signed-off-by: Steven Allen <[email protected]>
@Stebalien Stebalien mentioned this issue Oct 4, 2018
Merged
@ghost ghost assigned Stebalien Oct 4, 2018
@ghost ghost added status/in-progress In progress and removed status/ready Ready to be worked labels Oct 4, 2018
Stebalien added a commit that referenced this issue Oct 5, 2018
@Stebalien
don't use the domain name as a filename in /ipns/a.com
47e7f69 
fixes #5369

License: MIT
Signed-off-by: Steven Allen <[email protected]>
@ghost ghost removed the status/in-progress In progress label Oct 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Stebalien Stebalien

Labels
kind/bug A bug in existing code (including security flaws)
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

don't use the domain name as a filename in /ipns/a.com ipfs/kubo
4 participants
@eingenito @Stebalien @daviddias @Powersource