relative links in files not added

[autonome]

If I upload a dir of a basic static website (a basic html, js and css file) with ipfs-deploy, even though the js/css files are relatively linked I get this error when viewing the resulting hash:

The resource from “https://ipfs.infura.io/ipfs/style.css” was blocked due to MIME type (“text/plain”) mismatch (X-Content-Type-Options: nosniff).

Same website works fine when I do ipfs add -r ..

[hacdias]

@autonome it doesn't seem to be a problem of ipfs-deploy because the file is being correctly uploaded. Although infura.io gateway is sending the styles as text/plain and that, with X-Content-Type-Options: nosniff, won't allow it to be used.

Take this hash for example: QmUJgcsYqwcbyGAECgN5Ybcof524d7kBKoLHEZtFonRC3i. It has an index.html and a style.css.

On infura.io:

1. https://ipfs.infura.io/ipfs/QmUJgcsYqwcbyGAECgN5Ybcof524d7kBKoLHEZtFonRC3i
2. styles not used, text black on white bg.

On ipfs.io:

1. https://ipfs.io/ipfs/QmUJgcsYqwcbyGAECgN5Ybcof524d7kBKoLHEZtFonRC3i/
2. styles used, text white on black bg.

Hope it helps!

[autonome]

Hm, so this is an Infura problem? These types of gateway differences are exactly the type of incompatibility that trips up devs trying to do very basic things.

[autonome]

@lidel ^ Do we collect "developer adoption blockers" like this anywhere? It seems like we'd want gateways and companion behavior to be standardized. Do we have a spec for expected behavior?

[lidel]

@autonome I collect issues/bugs/caveats around HTTP semantics in ipfs/in-web-browsers#132, and want to use it as a seed to create "interop gateway tests" (ipfs/interop#76) that our and third party gateways could run to ensure they are compliant with "public gateway standard". (Not sure if its under maintenance or gateway-as-a-product. Something to discuss when planning OKRs for next quarter)

---

That being said, path /ipfs/style.css produces error which is returned as text/plain with nosniff header, but it is not the main problem. It looks like a bug in your website.
Are you sure your assets are requested via explicitly relative paths?

Assuming your assets are inassets/, it should look like

<link rel="stylesheet" href="./assets/main.css">

[hacdias]

@lidel on the example I linked below, the paths are explicitly relative, yes.

[lidel]

Indeed, I see there are two things at play here, which muddies the waters:

1. relative paths
2. gateway at ipfs.infura.io adding X-Content-Type-Options: nosniff to non-200 responses

@autonome I believe (2) should go away if (1) is solved – are you making HTML by hand, or generating it?

[wakqasahmed]

I deployed my pet-shop using ipfs-deploy, here is the error:

invalid ipfs path: invalid path "/ipfs/pets.json": invalid CID: selected encoding not supported

https://ipfs.io/ipfs/QmT6SgXKChuzz9nCTu8ZNtc8y7wLR3DjvH3rsEkcreiSDG/

Any ideas?

[hacdias]

@wakqasahmed hey! You seem to be loading the file pets.json from the wrong URL on js/app.js.

[wakqasahmed]

@hacdias may be my eyes are failing to see it, but can you explain how the following is wrong. I am loading ../pets.json and not pets.json

Here is the IPFS explorer details:
http://localhost:5001/webui/#/explore/QmT6SgXKChuzz9nCTu8ZNtc8y7wLR3DjvH3rsEkcreiSDG

[hacdias]

@wakqasahmed as far as I understand, ../pets.json is relative to to page you have opened at the moment and not to the JS file location (not sure though)

So, if you're on:

ipfs.io/ipfs/QmT6SgXKChuzz9nCTu8ZNtc8y7wLR3DjvH3rsEkcreiSDG

Then, ../pets.json will be

ipfs.io/ipfs/pets.json

if that js file will only be opened at that location, I'd suggest you to change ../pets.json to ./pets.json.

You might want to take advantage of HTML <base> tag which makes all relative links relative to the path enclosed in that tag.

[autonome]

Hmmm, so I made a new example testing loading external stylesheet and iframe with both raw relative path ("style.css") and dot slash ("./style.css"):

For first one I did "ipfs add -r ." in the directory and then typed "https://ipfs.io/ipfs/" in the url bar and pasted in the CID:

https://ipfs.io/ipfs/QmaXPQ28xM7h8AjnbJ8cD6Ux4mgvqtwGRYjgsxEPQ6kJTX/

While still in the same dir, I did "ipfs-deploy .", and it automatically opened a new tab with:

https://ipfs.infura.io/ipfs/QmaXPQ28xM7h8AjnbJ8cD6Ux4mgvqtwGRYjgsxEPQ6kJTX

Notice the difference? The ipfs.io gateway appends a trailing slash. If you remove it and reload, the gateway re-adds it. The content loads correctly in the ipfs.io gateway.

However the Infura URL does not load either relative path link, and does not automatically add a slash to the end.

If you manually add a slash, the content loads correctly in Infura URL:

https://ipfs.infura.io/ipfs/QmaXPQ28xM7h8AjnbJ8cD6Ux4mgvqtwGRYjgsxEPQ6kJTX/

So an easy fix in ipfs-deploy is to add the slash at the end of the URL opened by the tool.

Follow-ups could be to write a gateway spec for path handling, and file an issue with Infura about this behavior.

[lidel]

Thank you @autonome!

• added slash in fix: return URL with trailing slash #92, should fix the problem at hand
• added a note about redirect and mandatory slash for directory URLs to placeholder issue about interop Tests for HTTP Gateway, so we remember to test for this when gw interop suite is created. I believe gateway spec should be created along with the test suite.
• filled a bug at infura