|
HTTP Error 403
Forbidden
Introduction
The Web server (running the Web site) thinks that the
HTTP data stream sent by the client (e.g. your Web
browser or our CheckUpDown robot) was correct, but
access to the resource identified by the URL is
forbidden for some reason. Frank Vipond. September 2010.
This indicates a fundamental access problem, which may
be difficult to resolve because the HTTP protocol allows
the Web server to give this response without providing
any reason at all. So the 403 error is equivalent to a
blanket 'NO' by the Web server - with no further
discussion allowed.
By far the most common reason for this error is that
directory browsing is forbidden for the Web site. Most
Web sites want you to navigate using the URLs in the Web
pages for that site. They do not often allow you to
browse the file directory structure of the site. For
example try the following URL (then hit the 'Back'
button in your browser to return to this page):
This URL should fail with a 403 error saying "Forbidden:
You don't have permission to access
/accounts/grpb/B1394343/ on this server". This is because
our CheckUpDown Web site deliberately does not want you to
browse directories - you have to navigate from one
specific Web page to another using the hyperlinks in those
Web pages. This is true for most Web sites on the Internet
- their Web server has "Allow directory browsing" set OFF.
403 errors in the HTTP cycle
Any client (e.g. your Web browser or our CheckUpDown
robot) goes through the following cycle:
- Obtain an IP address from the IP name of the site
(the site URL without the leading 'http://'). This
lookup (conversion of IP name to IP address) is
provided by domain name servers (DNSs).
- Open an IP socket connection to that IP address.
- Write an HTTP data stream through that socket.
- Receive an HTTP data stream back from the Web server
in response. This data stream contains status codes
whose values are determined by the HTTP protocol.
Parse this data stream for status codes and other
useful information.
This error occurs in the final step above when the
client receives an HTTP status code that it recognises
as '403'.
Fixing 403 errors - general
You first need to confirm if you have encountered a "No
directory browsing" problem. You can see this if the URL
ends in a slash '/' rather than the name of a specific
Web page (e.g. .htm or .html). If this is your problem,
then you have no option but to access individual Web
pages for that Web site directly.
It is possible that there should be some content in the
directory, but there is none there yet. For example if
your ISP offers a 'Home Page' then you need to provide
some content - usually HTML files - for the Home Page
directory that your ISP assigns to you. Until the
content is there, anyone trying to access your Home Page
could encounter a 403 error. The solution is to upload
the missing content - directly yourself or by providing
it to your ISP. Once the content is in the directory, it
also needs to be authorised for public access via the
Internet. Your ISP should do this as a matter of course
- if they do not, then they have missed a no-brainer
step.
If the entire Web site is actually secured in some way
(is not open at all to casual Internet users), then an 401 - Not authorized
message could be expected. It is possible, but unlikely,
that the Web server issues an 403 message instead.
Some Web servers may also issue an 403 error if they at
one time hosted the site, but now no longer do so and
can not or will not provide a redirection to a new URL.
In this case it is not unusual for the 403 error to be
returned instead of a more helpful error. So if you have
recently changed any aspect of the Web site setup (e.g.
switched ISPs), then a 403 message is a possibility.
Obviously this message should disappear in time -
typically within a week or two - as the Internet catches
up with whatever change you have made.
If you think that the Web URL *should* be accessible to
all and sundry on the Internet and you have not recently
changed anything fundamental in the Web site setup, then
an 403 message indicates a deeper problem. The first
thing you can do is check the URL via a Web browser.
This browser should be running on a computer to which
you have never previously identified yourself in any
way, and you should avoid authentication (passwords
etc.) that you have used previously. Ideally all this
should be done over a completely different Internet
connection to any you have used before (e.g. a different
ISP dial-up connection). In short, you are trying to get
the same behaviour a total stranger would get if they
surfed the Internet to the Web page URL.
If this type of browser check indicates no authority
problems, then it is possible that the Web server (or
surrounding systems) have been configured to disallow
certain patterns of HTTP traffic. In other words, HTTP
communication from a well-known Web browser is allowed,
but automated communication from other systems is
rejected with an 403 error code. This is unusual, but
may indicate a very defensive security policy around the
Web server.
Fixing 403 errors - CheckUpDown
The first question is whether the Web page for your URL
is freely available to everyone on the Internet. If this
is not the case, then you may need to provide two items
2. Web Site User ID and 3. Web Site Password
for your CheckUpDown account - but only if the site uses
HTTP Basic Authentication. The Web Master or other IT
support people at the site will know what security and
authentication is used.
If however the Web page is open to all comers and there
have been no fundamental changes recently to how the Web
site is hosted and accessed, then an 403 message should
only appear if the Web server objects to some aspect of
the access we are trying to get to the Web site. Because
it indicates a fundamental authority problem, we can
only resolve this by negotiation with the personnel
responsible for security on and around the Web site.
These discussions unfortunately may take some time, but
can often be amicably resolved. You can assist by
endorsing our service to the security personnel. Please
contact us (email preferred) if you see persistent 403
errors, so that we can agree the best way to resolve
them.
|