mjackson/mach

Bikeshed color: "scriptName" and "pathInfo".

kriskowal opened this issue · 5 comments

kriskowal commented

I take these properties to mean "the portion of the location that has so far been routed" and "the portion of the location that remains to be routed". The names are left over from CGI where they made sense.

kriskowal commented

Picking up from #6.

kriskowal commented

"how i got here", "where i’m going".

mjackson commented

Right. I like to use the word location instead of scriptName because many times it indicates where an application is "mounted" within a larger app, e.g. within a strata or JSGI "urlmap". As far as pathInfo goes, I don't know the original intent of the "info" part. To me it's just a path, plain and simple.

kriskowal commented

For reference, consider this HTTP request:

GET /foo/bar
Host: example.com:8080

At present, the request has been routed up to "/foo".

  • "http://example.com:8080/foo/bar" is the fully qualified location for the whole request. Note that the Host header is optional; if the request was made by IP, it would not be included, and a fully qualified URL would not be available. That is why Node does not provide a fully qualified "url" property. The "host" is left to be divined from the headers and is only really useful for virtual hosts / host negotiation.
  • "/foo/bar" is the full path
  • "/foo" was scriptName
  • "/bar" was pathInfo

I’m favoring either sticking with the old broken names because they’re familiar and already implemented a dozen places, or switching to "path", "routedPath", and "remainingPath".

mjackson commented

I just committed a Request constructor that sticks with the old scriptName and pathInfo names for their CGI equivalents. I'm fine sticking with them as well.

The Request prototype has two getters, path and url that return the full path (i.e. scriptName + pathInfo properties) and fully qualified URL, respectively. Of course, it takes a bit of guesswork to figure out what the fully qualified URL is.