Cannot use subdomain gateway with ipfs subdomain

[Gunni]

ipfs-webui/src/bundles/gateway.js

Line 138 in b166caf

imgSubdomainUrl = new URL(`${gwUrl.protocol}//${IMG_HASH_1PX}.ipfs.${gwUrl.hostname}/?now=${Date.now()}&filename=1x1.png#x-ipfs-companion-no-redirect`)

This line prevents me from using ipfs.example.com as a subdomain gateway because it converts it to ipfs.ipfs.example.com…

If I type example.com instead, it generates a the subdomain gateway correctly but then tries the path gateway and and then fails anyway… what‽

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.tech if you just need general support.

[yhoungdev]

I would love to work on this issue.

[Gunni]

Can't you just remove the .ipfs part?

    imgSubdomainUrl = new URL(`${gwUrl.protocol}//${IMG_HASH_1PX}**.ipfs**.${gwUrl.hostname}/?now=${Date.now()}&filename=1x1.png#x-ipfs-companion-no-redirect`)

I mean, there exist a bunch of public gateways that don't use the ipfs subdomain.

[SuchitraSwain]

Please review

[Gunni]

You have not answered my question or resolved my review, please remove the code forcing the ipfs subdomain or explain why it is mandatory.

[lidel]

@Gunni what is the real world problem you are actually experiencing?

My understanding is that

• subdomain check is there for a reason: protect users from using misconfigured subdomain gateways
• there is no real gateway at https://example.com nor https://ipfs.example.com
• the subdomain test follows subdomain convention from the specification and is correctly failing (because the URL you provided is not a subdomain gateway)
• everything works as expected (user is unable to use broken gateway URL)

Am I missing anything here?
Are you experiencing a bug with a real subdomain gateway?
If so, provide URL of a real subdomain gateway (https://specs.ipfs.tech/http-gateways/subdomain-gateway/) where subdomain test does not work as expected.

[Gunni]

there is no real gateway at https://example.com nor https://ipfs.example.com

I was not aware of that.

the subdomain test follows subdomain convention from the specification

I was not aware of that.

[Gunni]

I used example.com as an accepted standard when discussing something that should function on the internet.

As described in RFC 2606 and RFC 6761, a number of domains such as example.com and example.org are maintained for documentation purposes. These domains may be used as illustrative examples in documents without prior coordination with us. They

I was attempting to make a gateway on my own domain, and the above issue stopped that.

I am not able to setup my gateway until this bug is fixed.

I wanted it to work as a subdomain gateway on *.ipfs.meh.is but a path gateway via ipfs.meh.is. It's obviously not working right now...

[lidel]

@Gunni did you read https://specs.ipfs.tech/http-gateways/subdomain-gateway/#host-request-header? what implementation if that spec are you using?

[Gunni]

I had not. But I also don't understand the question...

I am on the Kubo Settings page, Public Gateway, I enter in the Subdomain Gateway input box, and before even pressing submit, my browser loads:

https://ipfs.meh.is
- A request goes out to https://{CID}.ipfs.ipfs.meh.is/?now={TS}&filename=1x1.png which fails because ipfs subdomain is there twice

Ok so I try it without the subdomain:

https://meh.is
- A request goes out to https://{CID}.ipfs.meh.is/?now={TS}&filename=1x1.png#x-ipfs-companion-no-redirect which works, BUT
- Another request goes out, to https://meh.is/ipfs/{CID}?now={TS}&filename=1x1.png#x-ipfs-companion-no-redirect which is missing the ipfs. subdomain

I want to use ipfs.meh.is for BOTH subdomain AND path, which works btw, this webinterface just rejects it, that's what this bug is about...

Edit: Heck i'd even like if I could use ipfs.<domain>/{CID} but I assume from the standards that you always add ipfs to the path of a path gateway...

[lidel]

I want to use ipfs.meh.is for BOTH subdomain AND path,

This is not the right URL, unless you want to end up with ipfs.ipfs.:

• Subdomains provide origin isolation via cid.ipns. and id.ipns. subdomains.
• You have subdomain gateway configured at meh.is and NOT ipfs.meh.is (this is just a subdomain for hosting subdomains for immutable namespace)
• You should enter https://meh.is and not https://ipfs.meh.is

See docs and specs.

Real problem: missing CORS headers at https://meh.is

You should be using https://meh.is but the ipfs-webui refuses to accept your gateway because you don't have CORS headers configured correctly, blocking cross-origin requests:

Same error in Chrome:

How to fix

Note that setting https://w3s.link works fine (they have correct CORS set up):

This is because CORS preflight request sent by browser returns access-control-* headers in response:

$ curl -X OPTIONS https://w3s.link -i
access-control-allow-origin: *
access-control-allow-headers: Content-Type, Authorization
access-control-allow-methods: GET, HEAD, POST, OPTIONS
access-control-max-age: 86400

You need to set up your HTTP server to do the same, and it will pass the CORS check.

AFAIK there is no bug in ipfs-webui, and #2449 is not necessary, but lmk if I missed anything.

[Gunni]

The problem is, the meh.is server is cloudflare, and is entirely separate from the server at ipfs.meh.is.
I want to use ipfs.meh.is, even for path server via ipfs.meh.is/ipfs.
Othervise I'd only like to do subdomain server but this bug even blocks me from doing that because it checks both the subdomain and the path. But i can enter the fallback path gateway just fine by entering https://ipfs.meh.is in the second public gateway box.

Both https://{CID}.ipfs.meh.is/ AND https://ipfs.meh.is/ipfs/{CID} return the access-control-allow-origin headers directly from the ipfs application.

If I have to do it your way then I'd rather move both to a sub, and sub-sub domain, I'm that averse to using my apex domain, while I was absolutely fine with using the ipfs subdomain.