Http Status Codes
Status Codes
HTTP status codes are returned by web servers to describe if and how a request was processed. The codes are grouped by the first digit:
1xx - Informational
Any code starting with '1' is an intermediate response and indicates that the server has received the request but has not finished processing it. For example, IIS initially replies with 100 Continue when it receives a POST request and then with 200 OK once it has been processed
2xx - Successful
These codes are used when a request has been successfully processed. For example, the value 200 is used when the requested resource is being returned to the HTTP client in the body of the response message.
3xx - Redirection
Codes starting with a '3' indicate that the request was processed, but the browser should get the resource from another location. Some examples are:
| 302 | The requested resource has been temporarily moved and the browser should issue a request to the URL supplied in the Location response header. |
| 304 | The requested resource has not been modified and the browser should read from its local cache instead. The Content-Length header will be zero or absent because content is never returned with a 304 response |
4xx - Client Error
The server returns these codes when they is a problem with the client's request. Here are some examples:
| 401 | Anonymous clients are not authorized to view the requested content and must provide authentication information in the WWW-Authenticate request header. |
| 404 | The requested resource does not exist on the server |
5xx - Server Error
A status code starting with the digit 5 indicates that an error occurred on the server while processing the request. For example:
| 500 | An internal error occurred on the server. This may be because of an application error or configuration problem |
| 503 | The service is currently unavailable, perhaps because of essential maintenance or overloading |
Http Authentication
Here is a typical transaction between an HTTP client and an HTTP server running on the local machine (localhost). It comprises the following steps.
1. The client asks for a page that requires authentication but does not provide a user name and password. Typically this is because the user simply entered the address or followed a link to the page.
2. The server responds with the 401 response code and provides the authentication realm.
3. At this point, the client will present the authentication realm (typically a description of the computer or system being accessed) to the user and prompt for a user name and password. The user may decide to cancel at this point.
4. Once a user name and password have been supplied, the client adds an authentication header (with value base64encode(username+":"+password)) to the original request and re-sends it.
5. In this example, the server accepts the authentication and the page is returned. If the user name is invalid or the password incorrect, the server might return the 401 response code and the client would prompt the user again.
Note: A client may pre-emptively send the authentication header in its first request, with no user interaction required.
Http Encoding
When an HTTP client is reading a response message from a server it needs to know when it has reached the end of the message. This is particularly important with persistent (keep alive) connections, because a connection can only be re-used by another HTTP transaction after the response message has been fully received. The following sections describe the four ways in which an HTTP server can indicate the end of the response message:
Connection Closed by Server
The connection can be closed at the end of the response message by the server, but this prevents connections being re-used.
Content-Length Header
The length of the content after the response headers can be specified in bytes with the Content-Length header
Implied Content Length
Some types of responses, such as 304, are defined to never have content and therefore the client can assume that the response message is terminated by the double CRLF after the headers.
Chunked Encoding
The content can be broken up into a number of chunks; each of which is prefixed by its size in bytes. A zero size chunk indicates the end of the response message. If a server is using chunked encoding it must set theTransfer-Encoding header to "chunked".
Chunked encoding is useful when a large amount of data is being returned to the client and the total size of the response may not be known until the request has been fully processed. An example of this is generating an HTML table of results from a database query. If you wantedto use the Content-Length header you would have to buffer the whole result set before calculating the total content size. However, with chunked encoding you could just write the data one row at a time and write a zero sized chunk when the end of the query was reached.
ref:
Http Wiki - http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
Http header fields - http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
How to find ed of Http response - http://www.httpwatch.com/
HttpMessage structure - http://web-sniffer.net/
Http Message - http://www.w3.org/Protocols/
Http Authentication – http://en.wikipedia.org/wiki/Basic_access_authentication
HTTP Status Codes and Errors -http://www.httpwatch.com/httpgallery/errors/
http 1.1 RFC - http://www.w3.org/Protocols/rfc2616/rfc2616.html
http over TLS RFC - http://tools.ietf.org/html/rfc2818
ssl 3.0 RFC - http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00
