g1smd
msg:4511139 | 6:32 am on Oct 23, 2012 (gmt 0) |
Use the Live HTTP Headers extension for Firefox to examine the browser and server headers.
You'll see that's what you requested, rather than the server delivering some wierd redirect.
Add http:// to the link and you'll fix it.
|
slipkid
msg:4511169 | 8:13 am on Oct 23, 2012 (gmt 0) |
Thanks g1. You were correct. It seems I missed placing http:// in the links on a number of web pages and this inconsistency threw me into a state of confusion.
Thanks again for your help. I appreciate your quick response.
|
lucy24
msg:4511184 | 8:41 am on Oct 23, 2012 (gmt 0) |
There is no canonical or base reference in the <head>.
|
|
Doesn't need to be. It's implicit in HTML's handling of links.
Anyway, both forms are ... uhm ... not ideal :) http:// for your own site is overkill, and ../ is risky.
|
g1smd
msg:4511411 | 7:42 pm on Oct 23, 2012 (gmt 0) |
<a href="../utility/page.html">name</a> - dangerous form, do not use.
<a href="http://www.example.com/utility/page.html">name</a> - over-specified, but no problem.
<a href="/utility/page.html">name</a> - ideal format.
|
slipkid
msg:4511451 | 9:36 pm on Oct 23, 2012 (gmt 0) |
When I started my site some 14 years ago, I used MS Frontpage for authoring, and your option number 1 was the program's default method for referencing internal links.
I have abandoned FP and have been cleaning up the code for some time. I will try your method number three and test.
Thanks for the explanation of preferred practice.
|
g1smd
msg:4511452 | 9:41 pm on Oct 23, 2012 (gmt 0) |
Yes. Yet another thing we can blame Frontpage for.
It was done that way so you could easily preview pages without installing Apache or similar. It was a backward step.
|
|
