issue with http result....
>I use a package in tcl which implements the client-side of
> I'm working in tcl on a program I wrote which cycles through
> a database table of urls and reports each ones' status.
the http protocol. The functionality works except for one url
which keeps reporting a 404 - Not Found error, even though it
a) returns much quicker (the standard 404 - Not Found error
returns after it timesout at 2-minutes), and b) I can always
get to the url via my web browser.
Also, when I run the same set of commands from home I get a
200 - Ok status for the same url.
Now, at work I have to configure the http with a proxyhost and
proxyport, and I'm thinking that the url's server
just doesn't want to speak
to something running through a proxy to reach it .... On the
other hand, my browsers at work also work through proxies.
One more hint, I can actually fetch the body with the http
package, it's just the head (which is the bit I'm checking,
for the obvious reason of efficiency) that returns the errant
Has anyone seen this before? I'm trying to get through the
testing of my program, and I can't prove that it will work
better on the final site (which doesn't use proxies). Also,
this is only one link out of 40 or 50 in the test data. If the
proxies aren't the problem, then how do I know that once we
have thousands of links to manage that we won't have dozens
of such mistakes, which becomes very very annoying for a human
operator to check...
- On Thu, 20 Sep 2001 feit@... wrote:
> this is only one link out of 40 or 50 in the test data. If theYou will always have erroneous or otherwise unexpected responses if
> proxies aren't the problem, then how do I know that once we
> have thousands of links to manage that we won't have dozens
> of such mistakes, which becomes very very annoying for a human
> operator to check...
you use real URLs. There are a lot of odd servers out there. There is
no way around it. Using something like HEAD instead of GET will only
increase the number of servers not being able to respond correctly.
Do the best you can but accept some casualties.
In most cases, if your script works with thousands of links that you
do not control, then you do not care about a few wrong results. If you
control the sites your URLs point to, you should be able to have
more-or-less expected results after all bugs are sorted out.