N00b HTML question

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:

<a href=“samplefolder/samplefolder2/samplefile.html”>I’m dumb</a>

What is the correct way do internal links that are not in the same root directory?

edit: motherfucker, this is totally in the wrong subforum. Sorry guys. :(

That should work, if you’ve got your directory structure right.

Here’s a handy guide, though.

Worst comes to worst use an absolute link, like

http://www.whatever.com/folder/folder/folder/file.html

Argh, no, never, ever do that in-site.

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.

Why is that?

This is a much better solution. You can tell I’m no web-guru.

Because if the site ever moves, it’ll break.

I usually use “./folder/document.html”

As per the above link, using two periods will link to something in the parent directory, but a single one will keep it in the local folder.

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?

Ah, thank you guys very much. That was what was tricking me up. Adding “./” made the relative link point to the right place.

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.

Yeah, nothing worked without using that “./” first and then adding the rest of the path to the file. Is it a unix thing?

It really shouldn’t be a UNIX thing.

It might be instructive to attempt to figure out what the browser is resolving the URL without the “./” to. It should be throwing up a 404 at least.

http://www.webreference.com/html/tutorial2/3.html

Did you have a leading / on the url, and then changed it to ./?

<a href="/samplefolder/samplefolder2/samplefile.html">I’m dumb</a>

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?

Won’t prefixing it with “/” defeat the purpose of having a relative path?

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

Er, Apache IS the Unix webserver.

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.

fixed.

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.

Except that in Cubit’s case, it didn’t.

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.