search

ipfs-shipyard / ipfs-deploy

Zero-Config CLI to Deploy Static Websites to IPFS
Other
1.16k stars 123 forks source link

relative links in files not added #86

Closed autonome closed 5 years ago

autonome commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@autonome I collect issues/bugs/caveats around HTTP semantics in https://github.com/ipfs/in-web-browsers/issues/132, and want to use it as a seed to create "interop gateway tests" (https://github.com/ipfs/interop/issues/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 commented 5 years ago

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

lidel commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

wakqasahmed commented 5 years ago

@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

Screen Shot 2019-09-04 at 1 58 58 PM

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

hacdias commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

Thank you @autonome!