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.

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

Support protocols different from http / https #1

Open
Strepto opened this issue Jun 19, 2022 · 1 comment
Open

Support protocols different from http / https #1

Strepto opened this issue Jun 19, 2022 · 1 comment

Comments

@Strepto
Copy link

Strepto commented Jun 19, 2022

See: elm/url#10

This is a breaking change, but I think this should be handled early in Gren. Urls with non-http(s) protocols are common even in browsers as seen in the elm issue.

Maybe expanding the type Protocol = Https | Http | Scheme String to still support differentiating between http and https and other. But it might be even better to leave this parsing to the consuming code, and just redefine Protocol as Scheme, and do type Scheme = Scheme String

@avh4
Copy link

avh4 commented Jun 19, 2022

I think this is valuable. However, it's important to note that most of the fields in the current URL type (host, port, path, fragment) are not general attributes of URLs and the meaning and parsing is defined per scheme. The registry of URL schemes with links to the parsing specification for each is here https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

So imo if this were done, it should be done with consideration to actual use cases, and respect the actual specifications. Personally I'd suggest collecting specific examples of how this would be used. There are probably several common schemes that possibly follow the same structure as the http schemes and are relevant to web app development (file:, ipfs:, ftp:, etc) that I could see as reasonable to add (if all of those do in fact define port, host, path, query, fragment in the same way in their specifications). Beyond that, I'd also be interested to see examples where the app would value out of having URL support more schemes vs simply using the String type for URLs that aren't web URLs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants