Shouldn't IncomingMessage `url` property be named `uri` instead?

[ericmorand]

What is the problem this feature will solve?

Hello dear Node.js community.

A few days ago, I was giving a lesson to my students about HTTP/1.1 messaging, using Node.js http module to provide concrete examples of how an actual implementation may be used.

Then, a student came with a very interesting remark about the fact that, contrary to what I taught them ("a Request is a message with a resource identifier in its control data - a URI"), http.IncomingMessage exposes an attribute named url...which always holds a URI.

Typically, the url property holds the value /pub/WWW when the following message is presented to the server:

GET /pub/WWW/ HTTP/1.1
Host: www.example.org

Which is a legit URI, but not a legit URL - a URL MUST start with a protocol identifier, followed by a hostname...well you get the deal.

I think she is right: the url naming is confusing, it implies that the value held by the property is a URL, even though it is a URI.

What is the consensus about this?

Is she correct?

What is the feature you are proposing to solve the problem?

If my student is correct, would it be acceptable that, in future versions of the http module, a property uri is added to IncomingMessage, and url is marked as deprecated?

What alternatives have you considered?

No response

[ljharb]

imo it's still a URL because if you put it in a browser bar, it will load a webpage.

[ericmorand]

If you put /pub/www in your browser it won't load anything...except a search page of your browser have an unified address bar. /pub/www is not a URL. It is not recognised by browsers, or curl or wget.

And this is literally the content of the url property of IncomingMessage.

[ljharb]

true, it's a root-relative URL.

[jasnell]

Your student is partially correct.

URLs are a subset of URIs. That is, all URLs are URIs. So it is true to say that all http request URL's are actually URIs.

But, if we look at the RFC: https://www.rfc-editor.org/rfc/rfc7230.html#section-5.3 ... you'll find that the /pub/WWW part of GET /pub/WWW/ HTTP/1.1 is not actually always a URI... it is derived from the target URI.

That part of the request line is called the request-target, which has this definition:

Once an inbound connection is obtained, the client sends an HTTP
request message ([Section 3](https://www.rfc-editor.org/rfc/rfc7230.html#section-3)) with a request-target derived from the
target URI.  There are four distinct formats for the request-target,
depending on both the method being requested and whether the request
is to a proxy.

     request-target = origin-form
                    / absolute-form
                    / authority-form
                    / asterisk-form

The origin-form is an absolute-path plus an optional query. The absolute-path is nothing more than a sequence of one or more /-delimited segments. This would make it a path-absolute in URI terms (https://www.rfc-editor.org/rfc/rfc3986#section-3.3) or possibly a path-noscheme, and not an actual URI.

Only the absolute-form option is an absolute-URI. The rest aren't.

That all said, most developers are way more familiar with the term url than they are with the term uri, and most http applications use url rather than uri in commmon practice. So in this case, the API was named for the most common expectation rather than the most correct terminology.

Love that your student brought this up, btw ;-)