http(s) server why is request.url actually not an url, but a pathname. And why is parsing it now so hard?

[axkibe]

I'm putting this a discussion, since as feature request I don't have an idea how to solve it:

Back in the old days things were clear, in the handler to http(s) request one would write:

const url = require( 'url' );
const red = url.parse( request.url );

and then use "red" to deteremine what to serve. Was always okay to me.

But url.parse is depcrecated and WHATWG URL should be used.
But now this becomes for example:

const url = new URL(`http://${request.headers.host}${request.url}`)

But honestly, why do I now need to build an URL just to parse it again?

Why is "request.url" not an url, but a pathname? IMO this was a pretty awkward idea to put a pathname and call it "url". I know its been like this since 0.1 and probably due to backwards compatiblity never changed.. but you must admit, its really awkward, isn't it?

Or the docs say as an example:

new URL(request.url, `http://${request.headers.host}`); 

Which also makes http as protocol, albeit it was https.

In a better world request.url should IMO already an URL object. If not could we consider to make a getter for say request.URL (in captial letters) to be an URL object provided by the core?

[bnoordhuis]

The request may not have a Host header so I don't think it's feasible for http.Server to pre-construct an URL object.

[axkibe]

Couldn't we in this case just fill in the ip address of the interface the connection was made to?

Alternatively there should be a non-deprecated API that parses what "request.url" is (albeit it isn't an url) without having to patch together a made up URL by the user, just to parse it again.

[bnoordhuis]

Couldn't we in this case just fill in the ip address of the interface the connection was made to?

That won't work when the http.Server is listening on a UNIX socket. If you're behind a reverse proxy, the IP address is almost certainly not what you want to be using.

[axkibe]

In case of unix socket, maybe just use "localhost".. look I don't need the host, and generally I suppose no one wants that info, if its not there (or as you said with proxies is something else).. I want to parse the URL-fragment. It's just super strange to have to build a full pseudo string URL to parse the URL-fragment (what request.url shows). Now deprecated url.parse parsed these url fragments, but we should use WHATWG now, which doesn't and docs suggest building up pseudo hostnames to parse them again.

I realize there may not be a super easy way out of this mess. But I hope you realize this API has become kinda messed up, no?

[Rand0mF]

@axkibe absolutely agree, it even leads to more issues, as http frameworks build on top of it (express, fastify) and use request.url which does not match WHATWG standard. So you end up with your nodejs app treating incoming urls (route handlers) differently than what nodejs itself recommends in the docs, using WHATWG (and deprecating url.parse). fastify/fastify#5204 (comment)