So I have this sample HTML page on a school unix server. In index.html, I want to link to a file that is further down the directory tree. This doesn’t work:
Worst comes to worst, he just loads the document directly, then copies the URL out of the address bar and strips off the domain part to get the correct relative URL.
Right, I dimly recall the Unix convention that you need to explicitly specify with “./” when you want an item relative to the current directory. That was in shells but I guess web servers might work the same way?
Are you SURE that’s what the problem was? Because relative links should work just fine without any leading anything. Just look at, for example, the source for this very page. Not a “./” to be found except in the message text.
On the other hand, if that really was the problem, then the best I can guess it that your index.html isn’t actually sitting at your site root. In which case, I supposed you’d have to use BASE HREF to get your relative links working properly.
That’ll work, just the leading “/”. I’m not sure where “./” is coming from since that should be basically the same as adding nothing because “.” just means the current directory.
“/” to start off a path means start at the current root, this holds for both http page serving (start at the root of the current domain) and local filesystems (start at the root of the current disk filesystem) across virtually every modern OS.
And on my website (my ISP is running Apache IIRC) I don’t need any path prefix at all… but Cubit said in his first post he’s running on some school’s Unix server. Who knows what sort of ancient homebrew server software is running there?
Yeah, / is interpreted by the browser as being relative to the host root.
So /folder/folder/file.html is interpreted as www.site.com/folder/folder/file.html
And anyway, the server is irrelevant, because resolution of relative links is done by the browser, and every browser in the world will correctly resolve both “somedir/somepage.html” and “./somedir/somepage.html” exactly the same.
Also, there’s been a lot of different versions of Apache. Apache 2 and Apache 1 are pretty different.
And anyway, the server is irrelevant, because resolution of relative links is done by the browser, and every browser in the world will correctly resolve both “somedir/somepage.html” and “./somedir/somepage.html” exactly the same.
I’m pretty sure a Unix implementation can run more than one possible web server implementation. Like, an infinite variety of them – just as with any other type of application.
And if you think the browser should resolve server-side paths, explain why this doesn’t happen in Cubit’s case?
He’s misreporting the information. My guess is that he had a leading slash in one version and changed it to a ./ in the second. There’s simply no way that the webserver can make any difference at all in relative URL resolution; you can go look up the relevant specs and RFCs if you disbelieve me.