Re: [whatwg/url] Strictness on Port doesn't conform to URL/URI RFCs (Issue #883)

TechnicallyWeb3 left a comment (whatwg/url#883)

> URL has become unbelievably bloated and slow, we need to add more restrictions in my opinion and not reduce them. For example, if we simply didn't have `@` in the URLs, almost all URL parsers would be able to speed things up.

Username and password have been part of the URL/URI scheme since at least the early 2000s. Nowadays the user info in a URL/URI is generally discouraged.

Technically speaking no app needs to use the user info section of the authority but if an app needs it, it's available. Port numbers are also optional. Note: the only thing you actually **need** is the protocol and host. User, port, path and queries are all optional. 

> ```
> wttp://[[userAddress]-[userSignature]-][contractAddress/domainName]-[chainId]/[path][...standard URL queries&hash]
> ```
> 
> or using dot as a separator:
> 
> ```
> wttp://[[userAddress].[userSignature].][contractAddress/domainName].[chainId]/[path][...standard URL queries&hash]
> ```
> 
> or with segment name:
> 
> ```
> wttp://[useraddr.[userAddress]-sig.[userSignature]-]contactaddr.[contractAddress/domainName]-id.[chainId]/[path][...standard URL queries&hash]
> ```
> 
> Or numerous other ways.

The different symbols such as `@` and `:` actually help with parsing! It makes it significantly faster and more efficient.

Take the following example:
Domain: blog.my-little-pony.xyz
User: site-admin.1
Port: 8080
Path: /help

Under standard URI scheme it would look like this:
`http://site-admin.1@blog.my-little-pony.xyz:8080/help`

Under your proposed scheme it would be:
`http://site-admin.1-blog.my-little-pony.xyz-8080/help` or `http://site-admin.1.blog.my-little-pony.xyz.8080/help`

I feel like the parsing logic is far more complex when using the same uniform symbol.

Again most apps will use a simple format like:

`wttp://blog.tw3.eth/what-is-web3`

However, if I wanted to create a blog and I have authors submitting posts to the blockchain I may use an app which contains the address and signature of the author key to authenticate the permissions to write the post. It might look something like:

`wttp://user.eth:postsignature@blog.tw3.eth/makePost?file=mypost.md`

There are numerous ways to do this through the headers or body of the actual requests but I'm not here to tell developers how to build their apps.

> I also would disagree with the port number being conditionally bigger for non-special-schemes as well if that would be considered since the implementers pretty much have to use the bigger integer type.

Implementers wouldn't have to implement this to be above uint16.max they could use any unsigned integer. 

For example chain ID 1 is Ethereum mainnet and chain ID 137 is Polygon but the sepolia testnet is 11155111. For web3 our max "port" or chain ID would be ~uint64/2. 

In the case of http, ftp, telnet, https or any TCP/IP based protocol they'd need to implement the upper bound of uint16 in the apps themselves. But other protocols would use the port numbers as they need. In my case it's used as a chain ID. At the very least we could leave the standard as is and add an exception for non-TCP/IP protocols. 

Granted a lot of this stuff has been outdated. For example passing clear passwords in the URL is not recommended. I was simply demonstrating what a full URL would look like.

I don't mind using my "wide URL" (wURL) utility which extends the URL class (using WHATWG) to accept port strings if my proposal doesn't pan out. But while reading the URL/URI RFCs I noticed the discrepancy between WHATWG and the actual specs and decided to report the discrepancy as an issue. My motivation is to bring WHATWG into compliance with the actual URL specs. 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/883#issuecomment-3364167889
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/issues/883/3364167889@github.com>