Trailing slash: Difference between revisions

From Helpful
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 32: Line 32:




Interpretation of the URL is up to the server, so these are two different requests,
Interpretation of the URL is up to the server, so these are two different requests.
and the two ''could'' be made to display different content.  
 
The two ''could'' be made to display different content.
Or not.


In some cases that may be confusing {{comment|(and in the case of the root path, it's impossible because the path in the request - think {{inlinecode|GET / HTTP/1.0}} - can't be empty without it being a bad request{{verify}})}}.
In some cases that may be confusing {{comment|(and in the case of the root path, it's impossible because the path in the request - think {{inlinecode|GET / HTTP/1.0}} - can't be empty without it being a bad request{{verify}})}}.

Revision as of 15:49, 21 March 2024

In filesystem paths

In HTTP

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


Consider:

http://example.com/path
http://example.com/path/

Should these be considered the same?

The short answer is no.


Interpretation of the URL is up to the server, so these are two different requests.

The two could be made to display different content. Or not.

In some cases that may be confusing (and in the case of the root path, it's impossible because the path in the request - think GET / HTTP/1.0 - can't be empty without it being a bad request(verify)).


The question isn't

figuring out what to send to the user (that is usually well defined),
or even whether crawlers will get confused (they shouldn't.
In theory reacting to both is duplicate content, but not in a way they care much about).

The question is often whether there will ever be paths under that, because if so, that gets very messy immediately.


Consider that if you 'mount' an app under a path, e.g. so that the browser requests

/myapp/css

and 'mount' means you want the app to see

/css

...CGI-variable-wise (which only matters for frameworks that choose to adhere to these CGI variable conventions, but may do), this means moving elements from PATH_INFO to SCRIPT_NAME (or at least remove the lead-in path fro PATH_INFO), so that

  • the code that tests PATH_INFO for what to serve does not see that lead-in path.
  • http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO still points to the current script


All fine, but it leaves the question of what to do with the request to the exact path of

/myapp

If you do serve the app from that, then any relative paths the app gives back make no sense, because the UA will considers them relative to / and not to /myapp/

You can't fix that in the app (it's too late to change said semantics), so the proper solution is to have /myapp redirect to /myapp/ and have the app react only if that final slash is involved.

And that basically implies that your mounting logic has to know when to do that.


...but yes, there are various cases where you can get away with not doing that.

  • Say, if an app doesn't have any paths
  • when you can get away with guessing the best, or fix it dynamically
one example is where URL paths are mapped to filesystem paths, where you can figure out what to do based on directory entry
though even here, some servers will do external redirect to an URL with a /
but note that this only works within an app - not so much at its root