-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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.
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
Suborigin header must be lowercase #3209
Comments
wtf chromium!!! -- thanks for reporting :) I'll write up some IPFS feedback for the Suborigin working group soon and will take a look. |
Wow, that standard is going to be a wasted opportunity if we don't step in, @lgierth thank you-- will be a huge help if we can get Suborigins to behave like we need them to (basically like a different domain, and use any valid path) |
@lgierth Any update on the suborigin writeup? Lets not let this one slip away and be forgotten |
Right now I'm reading through the mailing list and current draft: https://w3c.github.io/webappsec-suborigins/ Tracking my progress in ipfs/specs#131 |
Okay I think we can fix this by using HSHCA for the suborigin value, in order to make it lower case. |
Suborigin
response header of gateway
Please see my other comment under the specs repo but in short therms: we should encode whole two segments of the path not only the multihash so it also works for ipns and other future protocols (ipld, view transformations and so on). |
The other day a discussion started about further restricting the characters allowed for suborigin names, and I expressed a preference for "ban starting with a number"/"disallow numerals" over "only lowercase a-z". |
I'm also getting this on the |
w3c/webappsec-suborigins#62 updates the rules for suborigin names:
|
The standard also allows some special values ( This means that we probably should have constant prefix so special values can't be hit by encoded hash. |
Yes agreed, it could be an unencoded
/ipns and /ipfs are naturally separated because there will never be anything within /ipfs with the same multihash or cid as something within /ipns and vice versa. For anything else that might come in the future, we can apply still apply prefixes without having to change the ones for /ipfs and /ipns. But I really don't have strong feelings about it, and this value is supposed to be opaque anyhow.
I can't find it anymore, but someone brought up suborigins and dnslink.
|
To fix it properly we need to decide on suborigin prefix and add cid.EncodeWithBase for chosen base encoding of CIDs. |
This existed before but was disabled in 912a972 because the Suborigin spec changed and it became incompatible. This commit updates the generated Suborigin header to be conformant with the latest spec. License: MIT Signed-off-by: James Stanley <[email protected]>
This existed before but was disabled in 912a972 because the Suborigin spec changed and it became incompatible. This commit updates the generated Suborigin header to be conformant with the latest spec. License: MIT Signed-off-by: James Stanley <[email protected]>
This existed before but was disabled in 912a972 because the Suborigin spec changed and it became incompatible. This commit updates the generated Suborigin header to be conformant with the latest spec. License: MIT Signed-off-by: James Stanley <[email protected]>
This existed before but was disabled in 912a972 because the Suborigin spec changed and it became incompatible. This commit updates the generated Suborigin header to be conformant with the latest spec. License: MIT Signed-off-by: James Stanley <[email protected]>
Quick update in the context of move to CIDv1 Base32 (https://github.com/ipfs/ipfs/issues/337, ipfs/in-web-browsers#66 (comment)). CIDv1Base32 is case-insensitive, so just prefix and use CID as-is: Location: CIDv0This one is bit smelly, right now its just a CIDv0 encoded in Base32: Location: https://ipfs.io/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR We can leave it as-is, or normalize it to CIDv1 Base32 to have the same string length everywhere. IPNSCase-insensitive representation of PeerIDs is an open issue: #5287 |
This was fixed by simply encoding the raw CID as base32. The new format is: |
Version/Platform/Processor information (from
ipfs version --all
):Type (bug, feature, meta, test failure, question): feature/bug
Area (api, commands, daemon, fuse, etc): gateway
Priority (from P0: operations on fire, to P4: functioning): P2
Description:
Using Chromium (
Version 53.0.2785.101 (64-bit)
) and the current Chrome for Android version I get the errorError with Suborigin header: Invalid character 'Q' in suborigin.
when opening any path on the gateway. It appears that this error stops any JS on the site from executing. I am testing it with a single page web app that works fine when the assets are served from a static webserver (e.g.python -m SimpleHTTPServer
).The request as made with curl:
From what I can gather from #651 the suborigin header is still in a very experimental stage on both the IPFS and the browser side. Thus I would propose a config flag that disables the
Suborigin
header being sent from the gateway, so it can be turned off until it is more stabilized.This is for you! Please read, and then delete this text before posting it.
The go-ipfs issues are only for bug reports and directly actionable features.
Check https://github.com/ipfs/community/blob/master/contributing.md#reporting-issues if that doesn't fit.
Check https://github.com/ipfs/go-ipfs/blob/master/docs/github-issue-guide.md if you are not sure how to fill this issue.
The text was updated successfully, but these errors were encountered: