A broken link preventer

[Craig Cockburn]

I have a tool which tells me the number of times that visitors attempt
to access a link from my site to an external site and what the response
code received was. In the event of the remote site returning an error
code, they are not sent to the remote site - why bother, it wouldn't
work!

Since I have over 1000 external links, this allows me to locate the
broken links that people see the most often and fix those first.
Conventional link checkers offer a complimentary service and detect
instances of broken links rather than instances of frequency seen.
The output from the program can generate reports based on time, link
accessed, page on my site where the link occurred and so on.

This means that on my site, I now have much better control over what
happens if the visitor would see a 404 on an external link and I can
offer them more options.

Try it out here
http://www.siliconglen.com/Scotland/2_2.html

Whilst accepting that broken links are a generally bad thing, this tool
at least helps me to manage them more effectively.

comments, feedback welcome. This is an early release so there may be
bugs but I hope not :-)

--
Craig Cockburn ("coburn"). http://www.SiliconGlen.com/
Home to the first online guide to Scotland, founded 1994.
Scottish FAQ, weddings, website design, stop spam and more!

[Chris Beall]

Craig Cockburn wrote:

I have a tool which tells me the number of times that visitors attempt
to access a link from my site to an external site and what the response
code received was. In the event of the remote site returning an error
code, they are not sent to the remote site - why bother, it wouldn't work!

Since I have over 1000 external links, this allows me to locate the
broken links that people see the most often and fix those first.
Conventional link checkers offer a complimentary service and detect
instances of broken links rather than instances of frequency seen.
The output from the program can generate reports based on time, link
accessed, page on my site where the link occurred and so on.

This means that on my site, I now have much better control over what
happens if the visitor would see a 404 on an external link and I can
offer them more options.

Try it out here
http://www.siliconglen.com/Scotland/2_2.html

Whilst accepting that broken links are a generally bad thing, this tool
at least helps me to manage them more effectively.

comments, feedback welcome. This is an early release so there may be
bugs but I hope not :-)

Craig,

Seems to work here and the suggestions provided to the user are helpful.

1. Rather than depend on UCSD, I'd suggest you provide your own
explanation of the error, showing only the one appropriate to the
immediate situation.

2. I used Netscape 7.1. When I see a list of links like those in your
example, I tend to keep the page with the list open in one tab, then
right click on each link I'm interested in and select "Open in new tab"
from the resulting popup menu. But something in your code prevents that
option (and several others) from appearing in the popup.

Chris Beall

[Steve Pugh]

Krustov wrote:

TMK if a website uses custom 404 pages then it wont show up as a broken
link .

Sometimes yes. But well configured web servers return 404 headers even
when displaying a custom 404 page. There are, of course, many badly
configured web servers out there.

Steve

[Philip Ronan]

"Steve Pugh" wrote:

Krustov wrote:

TMK if a website uses custom 404 pages then it wont show up as a broken
link .

Sometimes yes. But well configured web servers return 404 headers even
when displaying a custom 404 page. There are, of course, many badly
configured web servers out there.

I think the most common mistake is to use a fully qualified URL in the
ErrorDocument directive. For example:

ErrorDocument 404 http://example.com/error-docs/not_found.html

will cause the server to issue a 301 redirect header to the error page when
it can't find the requested document. The eror page will then be served with
a '200 OK" header.

It's all explained in the Apache documentation.

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

[Matt Probert]

On Tue, 06 Dec 2005 14:15:50 GMT, Philip Ronan
<in*****@invali d.invalid> wrote:

"Steve Pugh" wrote:

Krustov wrote:

TMK if a website uses custom 404 pages then it wont show up as a broken
link .

Sometimes yes. But well configured web servers return 404 headers even
when displaying a custom 404 page. There are, of course, many badly
configured web servers out there.

I think the most common mistake is to use a fully qualified URL in the
ErrorDocument directive. For example:

ErrorDocument 404 http://example.com/error-docs/not_found.html

will cause the server to issue a 301 redirect header to the error page when
it can't find the requested document. The eror page will then be served with
a '200 OK" header.

It's all explained in the Apache documentation.

Explained? That's an interesting term to use with regard to the Apache
documentation! I find the Apache documentation to be slightly less
intelligible than if it were written in Ancient Greek.

And as this is being widely cross-posted, perhaps a challenge could go
out for another techinal author - one who can decipher the Apache
documentation - to produce a version which can be widely understood.

Matt
--
The Probert Encyclopaedia - Beyond Britannica
http://www.probertencyclopaedia.com

[Philip Ronan]

"Matt Probert" wrote:

Explained? That's an interesting term to use with regard to the Apache
documentation! I find the Apache documentation to be slightly less
intelligible than if it were written in Ancient Greek.

This seems perfectly clear to me:

Note that when you specify an ErrorDocument that points to a remote URL
(ie. anything with a method such as "http" in front of it), Apache will
send a redirect to the client to tell it where to find the document,
even if the document ends up being on the same server. This has several
implications, the most important being that the client will not receive
the original error status code, but instead will receive a redirect
status code. This in turn can confuse web robots and other clients
which try to determine if a URL is valid using the status code.

<http://httpd.apache.or g/docs/1.3/mod/core.html#error document>

Where's the problem?

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

[Nick Kew]

Matt Probert wrote:

Explained? That's an interesting term to use with regard to the Apache
documentation! I find the Apache documentation to be slightly less
intelligible than if it were written in Ancient Greek.

OK, here's a simple challenge. Find another complex product with
documentation that's more readable than Apache's, while not being
misleading or downright wrong.

--
Nick Kew

[Jerry Stuckle]

Nick Kew wrote:

Matt Probert wrote:

Explained? That's an interesting term to use with regard to the Apache
documentation! I find the Apache documentation to be slightly less
intelligible than if it were written in Ancient Greek.

OK, here's a simple challenge. Find another complex product with
documentation that's more readable than Apache's, while not being
misleading or downright wrong.

MySQL
Microsoft's Visual Studio products
AutoCad
Websphere
Exim

To start.

Apache's documentation is some of the worst I've ever seen.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Nick Kew]

Jerry Stuckle wrote:

Nick Kew wrote:

Matt Probert wrote:

Explained? That's an interesting term to use with regard to the Apache
documentation! I find the Apache documentation to be slightly less
intelligible than if it were written in Ancient Greek.
OK, here's a simple challenge. Find another complex product with
documentation that's more readable than Apache's, while not being
misleading or downright wrong.

MySQL

Hmmm, that's a very readable manual, too.
Microsoft's Visual Studio products
You must be joking! Where do you find anything that isn't just a
longwinded explanation of how to use GUI menus? It certainly
never told me anything that wasn't bleedin' obvious.

Unlike back in the 1980s, when a microsoft manual was somewhat
helpful in learning C.
AutoCad
never used it.
Websphere
Put off even looking by the webpages and ambiguous license
(not sure if that's changed since IBM started to get more
serious about opensource).
Exim
Well, I chose postfix in preference when I last changed MTA,
and find postfix's documentation much harder than Apache's -
though nevertheless adequately workable.

To start.

Apache's documentation is some of the worst I've ever seen.

How so? Instead of whinging, how about some constructive criticism
that might offer some ideas for improving it?

--
Nick Kew

[Jerry Stuckle]

Nick Kew wrote:

Jerry Stuckle wrote:

Nick Kew wrote:

Matt Probert wrote:

Explained? That's an interesting term to use with regard to the Apache
documentation! I find the Apache documentation to be slightly less
intelligible than if it were written in Ancient Greek.


OK, here's a simple challenge. Find another complex product with
documentation that's more readable than Apache's, while not being
misleading or downright wrong.

MySQL

Hmmm, that's a very readable manual, too.

Microsoft's Visual Studio products

You must be joking! Where do you find anything that isn't just a
longwinded explanation of how to use GUI menus? It certainly
never told me anything that wasn't bleedin' obvious.

Unlike back in the 1980s, when a microsoft manual was somewhat
helpful in learning C.

AutoCad

never used it.

Websphere

Put off even looking by the webpages and ambiguous license
(not sure if that's changed since IBM started to get more
serious about opensource).

Exim

Well, I chose postfix in preference when I last changed MTA,
and find postfix's documentation much harder than Apache's -
though nevertheless adequately workable.

To start.

Apache's documentation is some of the worst I've ever seen.

How so? Instead of whinging, how about some constructive criticism
that might offer some ideas for improving it?

Let's see...

More examples on how to do things. More information on how different
commands interrelate. How to effectively use .htaccess (or place those
commands in your httpd.conf file if you have access to it).

And how about some developer documentation? There isn't anything other
than an old Apache 1.x book mainly written for Perl with C as a second
thought.

If the documentation is so good, why are there so many messages on
usenet by people trying to figure out how to do things?

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===