Menu
I've looked around the web for this before, and I suspect the answer is "you can't", but since I've not yet found an answer which is that definitive, I think it's worth asking here. The closest I've found touching on the problem is The mystery of the trailing slash and the relative url (which is currently down, but Google has a text-only cached version).
Because of the traditional design of URLs with a trailing slash being interpreted as a directory and those without a trailing slash being interpreted as a file resource, and relative URLs working off the directory, then if the current page has a path of
/lorem/ipsum/dolor a relative path of
not-dolor will resolve as
/lorem/ipsum/not-dolor which naturally makes sense, when /lorem/ipsum/dolor is viewed as a file resource, dolor, sitting in a directory, /lorem/ipsum/; typical, intuitive conventions. However, since a significant number of websites are now dynamic applications without a filesystem mapping for each URL, this can cause headaches, because sometimes you really want to work relative to the path as though, in the current design, there were a trailing slash.
Is there any reasonable way ("not involving server-side processing/variables/other, or JavaScript") of using a relative path based off the current path, and not the "directory" of the current path? So that not-dolor could be relative to /lorem/ipsum/dolor and produce
/lorem/ipsum/dolor/not-dolor There is no workaround that I know of involving something like ./not-dolor, since . is still (/lorem/)ipsum/. Short of redirecting to a trailing slash and making sure that all resources have URLs which correspond to a directory-ish and a file-ish nature, or modifying the spec(!), is there any way of tackling this?
294
If your site has a directory structure, it's more conventional to use a trailing slash with your directory URLs (for example, example.com/directory/ rather than example.com/directory ), but you can choose whichever you like. Be consistent with the preferred version. Use it in your internal links.
Rather than including the entire URL for each page you link, relative URLs cut down on the workload and time needed. For example, coding /about/ is much faster than https://www.example.com/about .
No.
The problem is not so much related to the director/file mapping (which has never been expected as how mappings would happen, only allowed as a convenient mapping, which still often are convenient).
It's more related to the simple fact that dolor is not the same as dolor/ and you want to give a new URI from a reference relative to dolor/ when combined to one ending in dolor.
What may be the solution, is to act with /lorem/ipsum/dolor/ all the time. That is to say, never talking about /lorem/ipsum/dolor at all, only ever about /lorem/ipsum/dolor/. After all, since the directory/file mapping is, as you say, not the only way to do things, there's no reason why your resource names shouldn't always end in slashes.
Indeed, this may make more sense anyway, as in using such relative links you are implying that there is some sort of relationship between /lorem/ipsum/dolor/not-dolor and /lorem/ipsum/dolor. Now, while /lorem/ipsum/dolor/not-dolor may not have much of a relationship to /lorem/ipsum/dolor/, the implication that it might is there in the URI (yes URIs are opaque, but also while they must be treated as opaque at some levels, they are allowed to reflect relationships, and this is precisely why relative URI references make sense). Arguably therefore, /lorem/ipsum/dolor/ more clearly reflects your overall URI-to-resource mapping (if it didn't, you wouldn't want to be going from dolor to not-dolor anyway).
Now, this comes down to redirecting to a trailing slash, which you say you want to avoid (or better yet, never leading someone to dolor in the first place), but its advantages now seem better than just the convenience of easier relative URIs.
129
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
