Does <A HREF hyperlink require "http://..."?

[Yeah]

Is it absolutely necessary to include "http://" in an A HREF hyperlink?
Would it be wise to remove this from one's Links page, just to save code?

[Bruce Lewis]

"Alan J. Flavell" <fl*****@physic s.gla.ac.uk> writes:

Apache is perfectly capable of being configured to return two
different valid resources in response to the two distinct URLs
http://www.example.com/xyz/abc and http://www.example.com/xyz/abc/ ,
but you have to work at it, it isn't something that happens by
accident. The default behaviour is the one that you (and most other
people) expect.

This was with Jetty, not Apache, but it happened by accident for me. On
ourdoings.com the URL parts that look like directories aren't. They are
looked up in a database. I had to write code to explicitly do the
redirect.

It's redirecting /favicon.ico to /favicon.ico/ at the moment. I'll have
to fix that some time.

--

http://ourdoings.com/ Easily organize and disseminate news and
photos for your family or group.

[Harlan Messinger]

Alan J. Flavell wrote:

On Thu, 5 Jan 2006, Harlan Messinger wrote:

On the other hand, IIS sends a redirect response when a directory is requested
without a trailing slash:

Client: give me http://www.example.com/xyz/abc
IIS: ask for http://www.example.com/xyz/abc/ instead.

I can't recall a web server which doesn't do that, by default.

OK, so it isn't an IIS quirk. Why the inefficient approach?

Pedants (such as DJ Delorie, who at one time had an explicit
demonstration on his web site in order to "make a point") have
to go to extra trouble if they want to disable that behaviour.
You say it's pedantry--to me, it's avoiding a pointless round trip.
Isn't it? Why would it make sense to handle the appending of a slash by
telling the client to try again, while handling on the server,
transparently to the client, the translation of a directory request WITH
the slash into a request for the default document in that directory?
[snip]

When the client makes the new request, THEN the server will send the
default file in the abc subdirectory.

Maybe. It depends. I've seen IIS servers which then issue yet
another redirection to default.asp

At least that's consistent--handling both steps inefficiently.

[Michael Winter]

On 05/01/2006 19:09, Harlan Messinger wrote:

[Redirecting to a canonical URI]

You say it's pedantry--to me, it's avoiding a pointless round trip.
Isn't it? Why would it make sense to handle the appending of a slash by
telling the client to try again [...]

Apache certainly think they have good reasons:

- The user is finally requesting the canonical URL of the
resource
- mod_autoindex works correctly. Since it doesn't emit the path
in the link, it would point to the wrong path.
- DirectoryIndex will be evaluated only for directories
requested with trailing slash.
- Relative URL references inside html pages will work
correctly.

-- DirectorySlash Directive, Apache Modules mod_dir[1]

Mike
[1] <http://httpd.apache.or g/docs/2.0/mod/mod_dir.html#di rectoryslash>

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Alan J. Flavell]

On Thu, 5 Jan 2006, Harlan Messinger wrote:

OK, so it isn't an IIS quirk. Why the inefficient approach?
It isn't an "inefficien t" approach, it's an error fixup. Short of
rejecting the URL as invalid, it's the least-cost fixup for the error.

Pedants (such as DJ Delorie, who at one time had an explicit
demonstration on his web site in order to "make a point") have to
go to extra trouble if they want to disable that behaviour.

You say it's pedantry--to me, it's avoiding a pointless round trip.

His page returned by the URL without the trailing slash was a tutorial
page explaining that the URL without the trailing slash didn't really
exist, requesting it was an error, and the proper thing to do if one
wanted the URL with the trailing slash was to *ask* for the URL with
the trailing slash, thus avoiding the need for the server to waste
resources issuing the redirection to correct the error.

"And so say all of us".
Why would it make sense to handle the appending of a slash by
telling the client to try again,

It's the only way to get back into synch for resolving relative URLs.

[Harlan Messinger]

Alan J. Flavell wrote:

On Thu, 5 Jan 2006, Harlan Messinger wrote:

OK, so it isn't an IIS quirk. Why the inefficient approach?

It isn't an "inefficien t" approach, it's an error fixup. Short of
rejecting the URL as invalid, it's the least-cost fixup for the error.

Pedants (such as DJ Delorie, who at one time had an explicit
demonstratio n on his web site in order to "make a point") have to
go to extra trouble if they want to disable that behaviour.

You say it's pedantry--to me, it's avoiding a pointless round trip.

His page returned by the URL without the trailing slash was a tutorial
page explaining that the URL without the trailing slash didn't really
exist, requesting it was an error, and the proper thing to do if one
wanted the URL with the trailing slash was to *ask* for the URL with
the trailing slash, thus avoiding the need for the server to waste
resources issuing the redirection to correct the error.

"And so say all of us".

Why would it make sense to handle the appending of a slash by
telling the client to try again,

It's the only way to get back into synch for resolving relative URLs.

I was wishing you'd explained this further, but I guess I just figured
it out. It's that the *client* doesn't know, when it sends a request
without a trailing slash, that the URL will resolve on the server to a
directory rather than to a document. So, for example, if the request was for

http://www.example.com/xyz/abc

and a document were returned, the client would think the document was
abc in the directory xyz rather than some anonymous default document in
directory xyz/abc. If the user activated a link in this document defined
by the tag <a href="123.html" >, the client would send a request for

http://www.example.com/xyz/123.html

when the link was intended to lead to

http://www.example.com/xyz/abc/123.html

Is that it?

[Stan Brown]

Thu, 05 Jan 2006 11:39:27 -0500 from Harlan Messinger
<hm************ *******@comcast .net>:

Stan Brown wrote:

In article <nm************ *@grumpy-fuzzball.mit.ed u>,
Bruce Lewis <br*****@yahoo. com> wrote:

>I want to amplify Darin's reference, because this page includes the
>important example href="./" that is too often neglected.

Eric Lindsay:

I like that. So the idea is you could change all your references now to
an older style default file like href="index.htm " to href="./" [...]

Yes, and this is a great time saving if you later have to migrate to
a different server such as an IIS one where the default is
"default.ht m" or "default.ht ml". On at least one such server, I found
"index.htm" didn't work.

With IIS you can set the default document for a directory or for a whole
site to anything you want.

Yes, if you have the privilege to do so -- which I didn't. And the
fellow who did have privilege was unwilling to tweak any settings
because he didn't understand IIS. (Given that it's Microsoft
software, I sympathized.) So I set my _local_ Apache to find only
"default.ht m", and then I could test what the IIS server would do
before I uploaded files to it.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

[Stan Brown]

Thu, 05 Jan 2006 12:08:38 -0500 from Harlan Messinger
<hm************ *******@comcast .net>:

On the other hand, IIS sends a redirect response when a directory is
requested without a trailing slash:

When the client makes the new request, THEN the server will send the
default file in the abc subdirectory. Do other web servers do this?

Apache does. Perhaps a better question is, is there Web server that
_doesn't_? :-)

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

[David Ross]

Mark Parnell wrote:

Deciding to do something for the good of humanity, David Ross
<no****@nowhere .not> spouted in comp.infosystem s.www.authoring.html:

<a href="mail:no** **@nowhere.not" >Mail to me</a>

I think you mean mailto: not mail:

With all the standard caveats (i.e. it may not work) of course.

Of course!

I was once told that we are each allowed to make one mistake per
day. This one brings me up to 14 July 1996. :) (My wife would
say it brings me to 23 October 2019.)

--

David E. Ross
<http://www.rossde.com/>

Concerned about someone (e.g., Pres. Bush) snooping
into your E-mail? Use PGP.
See my <http://www.rossde.com/PGP/>

[David Ross]

"Eric B. Bednarz" wrote [in part]:

I previously wrote [also in part]:

Specifying a particular news server would be

Undocumented?

Where a proprietary newsgroup (e.g., hosted on only one server and
not propagated across the NNTP universe), indicating the server not
only works but is also ver useful to anyone who does already
subscribe to that server.

For testing, links relative to my home page allow me to recreate my
Web site in a local directory on my PC. This means that I can
navigate through my site without even connecting to the Internet.

Setting up a local web server shouldn't take more than 15 minutes for a
first time attempt even on win98. Besides the benefits of a real test
environment, you cannot seriously want to include the DirectoryIndex
file names in your relative URI references?

I'm not sure what you mean by "the DirectoryIndex file names". If
you look at the source of any of my pages (e.g., my site map at
<http://www.rossde.com/sitemap.html>), you will see that all my
pages reference each other relatively. Thus, from the source of my
site map, you will see that my main PGP page (cited in my signature
below) is at <PGP/index.html>. On both my PC and my ISP's Web
server, there is a directory (folder) named PGP under my domain
root. Thus, if you are at <http://www.rossde.com/>, the main PGP
page is at <PGP/index.html>. Compare this with the link for that
same page in my signature.

--

David E. Ross
<http://www.rossde.com/>

Concerned about someone (e.g., Pres. Bush) snooping
into your E-mail? Use PGP.
See my <http://www.rossde.com/PGP/>

[Alan J. Flavell]

On Thu, 5 Jan 2006, Harlan Messinger wrote, quoting me:

It's the only way to get back into synch for resolving relative
URLs.

[..] So, for example, if the request was for

http://www.example.com/xyz/abc

and a document were returned, the client would think the document
was abc in the directory xyz rather than some anonymous default
document in directory xyz/abc. If the user activated a link in this
document defined by the tag <a href="123.html" >, the client would
send a request for

http://www.example.com/xyz/123.html

when the link was intended to lead to

http://www.example.com/xyz/abc/123.html

Is that it?

You've got it!

But try to stand clear of the term "directory" in URLs. In a sense,
the URL hierarchy does define some kind of abstract file system "in
URL space", but just exactly how that abstract file system maps to a
real file system inside the server is entirely a private concern of
the server and its configuration. It might be anything from a
straight URL-to-filesystem mapping, to a relational database lookup
with no real "file system" structure involved at all.

Navigating around the URL hierarchy is something that happens *in that
abstract URL hierarchy*. As soon as one gets confused and starts
trying to use it to navigate around the server's file system, things
are likely start falling apart. *First* resolve relative references
*in the URL hierarchy space*, and only *then* go mapping the resulting
absolute URL references into the server's resource space (file system,
CGI scripts, database lookups, whatever the server uses). Can't
emphasise that too strongly.

cheers