|
Many people have asked
exactly what counts as a request, and the meaning of other terms used in
the reports. Here is an explanation. In addition, following the
description of the report structure, there is an excerpt from RFC 1945,
which details the Different HTTP status codes you may see reference to
in this report.
- Request
- Each time someone
requests a file from your server, that counts as a request. It may
be that the page contains some in-line images. If so, they must be
loaded separately by people with graphical browsers, which counts as
further requests.
Unfortunately, you
cannot tell how many times your file has been read from this. The
user may in fact request the file from a proxy server which already
has a copy of it, or retrieve it from a local cache. In these cases
no connection is made to your server, and no request is scored.
There are three
categories of request:
- Completed
(or successful) requests
- Those requests
with status codes in the 200s (where the document was returned)
or with code 304 (where the document was not needed because it
had not been recently modified and the user could use a cached
copy).
- Redirected
requests
- Those requests
with other status codes in the 300s. The most common cause of
these requests is that the user has incorrectly requested a
directory name without the trailing slash (ie: http://mydomain.com/foo
instead of http://mydomain.com/foo/). The server replies with a
redirection ("you probably mean the following") and the user
then makes a second connection to get the correct document
(although usually the browser does it automatically without the
user's intervention or knowledge).
- Failed
requests
- Those requests
with status codes in the 400s (error in request) or 500s (server
error). They come about for a variety of reasons, but the most
common are when the requested file is not found or is
read-protected.
Note that 302
requests are not counted. Most of them come about by the user
requesting a faulty URL, as explained above. However, some CGI
scripts also return a 302 code; these are not included because there
is no way to tell them apart from the first type.
- Total data
transferred
- Refers only to
successful requests, and does not include the message header, only
the actual data. The detailed reports also only include successes.
- Page Request
- A page request
consists of any request for a file matching one of the following
expressions:
- Corrupt logfile
lines
- Those log file
lines we can't understand.
- Unwanted lines
- Those log file
entries that refer to files, hosts or dates that we have
specifically excluded.
- Host
- a computer that
has requested something from your server. UUNET reports give the
number of distinct (different) hosts that have made a successful
request, and the number of distinct files they have requested.
HTTP Status codes
(taken from the
Specifications as drafted by T. Berners-Lee, R. Fielding and H. Frystyk)
W3C
Archive of HTTP 1.0 specifications (Informational RFC 1945)
The individual values
of the numeric status codes defined for HTTP/1.0, and an example set of
corresponding Reason-Phrase's, are presented below. The reason phrases
listed here are only recommended -- they may be replaced by local
equivalents without affecting the protocol. These codes are fully
defined in Section 9.
Status-Code = "200" ; OK
| "201" ; Created
| "202" ; Accepted
| "204" ; No Content
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "304" ; Not Modified
| "400" ; Bad Request
| "401" ; Unauthorized
| "403" ; Forbidden
| "404" ; Not Found
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| extension-code
Each Status-Code is
described below, including a description of which method(s) it can
follow and any meta-information required in the response.
This class of status
code indicates a provisional response, consisting only of the
Status-Line and optional headers, and is terminated by an empty line.
HTTP/1.0 does not define any 1xx status codes and they are not a valid
response to a HTTP/1.0 request. However, they may be useful for
experimental applications which are outside the scope of this
specification.
This class of status
code indicates that the client's request was successfully received,
understood, and accepted.
The request has
succeeded. The information returned with the response is dependent on
the method used in the request, as follows:
- GET
- an entity
corresponding to the requested resource is sent in the response;
- HEAD
- the response must
only contain the header information and no Entity-Body;
- POST
- an entity
describing or containing the result of the action.
The request has been
fulfilled and resulted in a new resource being created. The newly
created resource can be referenced by the URI(s) returned in the entity
of the response. The origin server should create the resource before
using this Status-Code. If the action cannot be carried out immediately,
the server must include in the response body a description of when the
resource will be available; otherwise, the server should respond with
202 (accepted).
Of the methods defined
by this specification, only POST can create a resource.
The request has been
accepted for processing, but the processing has not been completed. The
request may or may not eventually be acted upon, as it may be disallowed
when processing actually takes place. There is no facility for
re-sending a status code from an asynchronous operation such as this.
The 202 response is
intentionally non-committal. Its purpose is to allow a server to accept
a request for some other process (perhaps a batch-oriented process that
is only run once per day) without requiring that the user agent's
connection to the server persist until the process is completed. The
entity returned with this response should include an indication of the
request's current status and either a pointer to a status monitor or
some estimate of when the user can expect the request to be fulfilled.
The server has
fulfilled the request but there is no new information to send back. If
the client is a user agent, it should not change its document view from
that which caused the request to be generated. This response is
primarily intended to allow input for scripts or other actions to take
place without causing a change to the user agent's active document view.
The response may include new meta-information in the form of entity
headers, which should apply to the document currently in the user
agent's active view.
This class of status
code indicates that further action needs to be taken by the user agent
in order to fulfill the request. The action required may be carried out
by the user agent without interaction with the user if and only if the
method used in the subsequent request is GET or HEAD. A user agent
should never automatically redirect a request more than 5 times, since
such redirections usually indicate an infinite loop.
This response code is
not directly used by HTTP/1.0 applications, but serves as the default
for interpreting the 3xx class of responses.
The requested resource
is available at one or more locations. Unless it was a HEAD request, the
response should include an entity containing a list of resource
characteristics and locations from which the user or user agent can
choose the one most appropriate. If the server has a preferred choice,
it should include the URL in a Location field; user agents may use this
field value for automatic redirection.
The requested resource
has been assigned a new permanent URL and any future references to this
resource should be done using that URL. Clients with link editing
capabilities should automatically relink references to the Request-URI
to the new reference returned by the server, where possible.
The new URL must be
given by the Location field in the response. Unless it was a HEAD
request, the Entity-Body of the response should contain a short note
with a hyperlink to the new URL.
If the 301 status code
is received in response to a request using the POST method, the user
agent must not automatically redirect the request unless it can be
confirmed by the user, since this might change the conditions under
which the request was issued.
Note: When
automatically redirecting a POST request after receiving a 301
status code, some existing user agents will erroneously change it
into a GET request.
The requested resource
resides temporarily under a different URL. Since the redirection may be
altered on occasion, the client should continue to use the Request-URI
for future requests.
The URL must be given
by the Location field in the response. Unless it was a HEAD request, the
Entity-Body of the response should contain a short note with a hyperlink
to the new URI(s).
If the 302 status code
is received in response to a request using the POST method, the user
agent must not automatically redirect the request unless it can be
confirmed by the user, since this might change the conditions under
which the request was issued.
Note: When
automatically redirecting a POST request after receiving a 302
status code, some existing user agents will erroneously change it
into a GET request.
If the client has
performed a conditional GET request and access is allowed, but the
document has not been modified since the date and time specified in the
If-Modified-Since field, the server must respond with this status code
and not send an Entity-Body to the client. Header fields contained in
the response should only include information which is relevant to cache
managers or which may have changed independently of the entity's
Last-Modified date. Examples of relevant header fields include: Date,
Server, and Expires. A cache should update its cached entity to reflect
any new field values given in the 304 response.
The 4xx class of status
code is intended for cases in which the client seems to have erred. If
the client has not completed the request when a 4xx code is received, it
should immediately cease sending data to the server. Except when
responding to a HEAD request, the server should include an entity
containing an explanation of the error situation, and whether it is a
temporary or permanent condition. These status codes are applicable to
any request method.
Note: If the client
is sending data, server implementations on TCP should be careful to
ensure that the client acknowledges receipt of the packet(s)
containing the response prior to closing the input connection. If
the client continues sending data to the server after the close, the
server's controller will send a reset packet to the client, which
may erase the client's unacknowledged input buffers before they can
be read and interpreted by the HTTP application.
The request could not
be understood by the server due to malformed syntax. The client should
not repeat the request without modifications.
The request requires
user authentication. The response must include a WWW-Authenticate header
field (Section
10.16) containing a challenge applicable to the requested resource.
The client may repeat the request with a suitable Authorization header
field (Section
10.2). If the request already included Authorization credentials,
then the 401 response indicates that authorization has been refused for
those credentials. If the 401 response contains the same challenge as
the prior response, and the user agent has already attempted
authentication at least once, then the user should be presented the
entity that was given in the response, since that entity may include
relevant diagnostic information. HTTP access authentication is explained
in
Section 11.
The server understood
the request, but is refusing to fulfill it. Authorization will not help
and the request should not be repeated. If the request method was not
HEAD and the server wishes to make public why the request has not been
fulfilled, it should describe the reason for the refusal in the entity
body. This status code is commonly used when the server does not wish to
reveal exactly why the request has been refused, or when no other
response is applicable.
The server has not
found anything matching the Request-URI. No indication is given of
whether the condition is temporary or permanent. If the server does not
wish to make this information available to the client, the status code
403 (forbidden) can be used instead.
Response status codes
beginning with the digit "5" indicate cases in which the server is aware
that it has erred or is incapable of performing the request. If the
client has not completed the request when a 5xx code is received, it
should immediately cease sending data to the server. Except when
responding to a HEAD request, the server should include an entity
containing an explanation of the error situation, and whether it is a
temporary or permanent condition. These response codes are applicable to
any request method and there are no required header fields.
The server encountered
an unexpected condition which prevented it from fulfilling the request.
The server does not
support the functionality required to fulfill the request. This is the
appropriate response when the server does not recognize the request
method and is not capable of supporting it for any resource.
The server, while
acting as a gateway or proxy, received an invalid response from the
upstream server it accessed in attempting to fulfill the request.
The server is currently
unable to handle the request due to a temporary overloading or
maintenance of the server. The implication is that this is a temporary
condition which will be alleviated after some delay.
Note: The existence
of the 503 status code does not imply that a server must use it when
becoming overloaded. Some servers may wish to simply refuse the
connection.
|
