All HTTP messages (requests and responses) consist of one or
more headers, each on a separate line, followed by a mandatory blank line, followed by an optional message body.
The first line of every HTTP request consists of three items, separated by spaces:
which indicates the HTTP method. The most commonly used method is GET,
whose function is to retrieve a resource from the web server. GET
not have a message body, so there is no further data following the blank
line after the message headers.
The requested URL. The URL functions as a name for the resource being
requested, together with an optional query string containing parameters that the client is passing to that resource.
The HTTP version being used. The only HTTP versions in common use on
the Internet are 1.0 and 1.1, and most browsers use version 1.1 by
There are a few differences between the specifications of these two versions; however, the only difference you are likely to encounter when attacking web applications is that in version 1.1 the host request header is mandatory.
The first line of every HTTP response consists of three
items, separated by spaces:
The HTTP version being used.
A numeric status code indicating the result of the request. 200 is the most common status code; it means that the request was successful and the requested resource is being treturned.
A textual "reason phrase" further describing the status of the
response. This can have any value and is not used for any purpose by current
The two main methods are GET and POST. There are others such
as the following:
This functions in the same way as a GET request except that the
should not return a message body in its response. The server should return
the same headers that it would have returned to the corresponding GET
request. Hence, this method can be used for checking whether a resource is
present before making a GET request for it.
This method is designed for diagnostic purposes. The server
return in the response body the exact contents of the request message that
it received. This can be used to detect the effect of any proxy servers
between the client and server that may manipulate the request. It can also
sometimes be used as part of an attack against other applications users.
This method asks the server to report the HTTP methods that are
available for a particular resource. The server will typically return a
response containing an Allow header that lists the available methods.
This method attempts to upload the specified resource to the
the content contained in the body of the request. If this method is
enabled, then you may be able to leverage it to attack the application;
for example, by uploading an arbitrary script and executing this on the server.
NOTE: The correct technical term for a URL is actually URI (or
uniform resource identifier), but this term is really only used in formal specifications.)
HTTP header fields provide required information about the request or response, or about the object sent in the message body.
This is used to inform the other end of the communication whether it should close the TCP connection after the HTTP transation has completed or keep it open for further messages.
This is used to specify what kind of encoding is being used for the content contained in the message body, such as gzip, which is used by some applications to compress responses for faster transmission.
This is used to specify the length of the message body, in bytes (except in the case of responses to HEAD requests, when it indicates the length of the body in the response to the corresponding GET request).
This is used to specify the type of content contained in the message body; for example, text/html for HTML documents.
This is used to specify any encoding that was performed on the message body to facilitate its transfer over HTTP. It is normally used to specify chunked encoding when this is employed.
This is used to tell the server what kinds of content the client is willing to accept, such as image types, office document formats, and so on.
This is used to tell the server what kinds of content encoding the client is willing to accept.
This is used to submit credentials to the server for one of the built-in HTTP authentication types.
This is used to submit cookies to the server which were previously issued by it.
This is used to specify the hostname that appeared in the full URL being requested.
This is used to specify the time at which the browser last received the requested resource. If the resource has not changed since that time, the server may instruct the client to use its cached copy, using a response with status code 304.
This is used to specify an entity tag, which is an identifier denoting
the contents of the message body. The browser submits the entity tag that
the server issued with the requested resource when it was last received.
The server can use the entity tag to determine whether the browser may use its cached copy of the resource.
This is used to specify the URL from which the current request
This is used to provide information about the browser or other client software that generated the request.
This is used to pass caching directives to the browser (for example, no-cache)
This is used to specify an entity tag. Clients can submit this identifier
in future requests for the same resource in the If-None-Match header to
notify the server which version of the resource the browser currently holds in its cache.
This is used to instruct the browser how long the contents of the message
body are valid for. The browser may use the cached copy of this resource
until this time.
This is used in redirection responses (those with a status code starting
with a 3) to specify the target of the redirect.
This is used to pass caching directive to the browser (for example, no cache).
This is used to provide information about the web server software being used.
This is used to issue cookies to the browser that it will submit back to the server in subsequent requests.
This is used in responses with a 401 status code to provide details of
the type(s) of authentication supported by the server.
The cookie mechanism enables the server to send items of data to the client, which the client stores and resubmits back to the server.
Used to set a date until which the cookie is valid. This will cause the browser to save the cookie to persistent storage, and it will be reused in subsequent browser sessions until the expiration date is reached. If this attribute is not set, the cookie is used only in the current browser session.
Used to specify the domain for which the cookie is valid. This must be the same or a parent of the domain from which the cookie is received.
Used to specify the URL path for which the cookie is valid.
If this attribute is set, the the cookie will only ever be submitted in the HTTPS requests.
If this attribute is set, then the cookie cannot be directly accessed
HTTP Status Codes
Each HTTP response message must contain a status code in its
first line, indicating the result of the request. The status codes fall into five groups, accoding to the first digit of the code.
1xx - Informational.
2xx - The request was successful.
3xx - The client is redirected to a different resource.
4xx - The request contains an error of some kind.
5xx - The server encountered an error fulfilling the
Below is a list of common HTTP status codes:
This response is sent in some circumstances
when a client submits a request containing a body. The response indicates that
the request headers were received and that the client should continue sending the body. The server will then return a second response when the request has been completed.
This indicates that the request was successful and
the response body contains the result of the request.
This is returned in response to a PUT request
to indicate that the request was successful.
301 Moved Permanently
This redirects the browser permanently to a different URL, which is specified in the Location header. The client should use the new URL in the future rather than the original.
This redirects the browser temporarily to a
different URL, which is specified in the Location header. The client should revert to the original URL in subsequent requests.
304 Not Modified
This instructs the browser to use its
cached copy of the requested resource. The server uses the
If-None-Match request headers to determine whether the client has
the latest version of the resource.
400 Bad Request
This indicates that the client submitted
an invalid HTTP request. You will probably encounter this when you have
modified a request in certain invalid ways, for example by placing a space character into the URL.
The server requires HTTP authentication before the request will be granted. The WWW-Authenticate header contains details of the type(s) of authentication supported.
This indicates that no one is allowed to
access the requested resource, regardless of authentication.
404 Not Found
This indicates that the requested resource does not exist.
405 Method Not Allowed
This indicates that the method used in the request is not
supported for the specified URL. For example, you may
receive this status code if you attempt to use the PUT method where it is not supported.
413 Request Entity Too Large
If you are probing for buffer overflow vulnerabilities in native code, and so submitting long strings of data, this indicates that the body of your request is too large for the server to handle.
414 Request URI Too Long
Similar to the previous response, this indicates that the URL used in the request is too large for the server to handle.
500 Internal Server Error
This indicates that the server encountered an error fulfilling the
request. This normally occurs when you have
submitted unexpected input that caused an unhandled error somewhere within the application's processing. You should review the full contents of the server's response closely for any details indicating the nature of the error.
503 Service Unavailable
This normally indicates that, although the web server itself
is functioning and able to respond to requests,
the application accessed via the server is not responding. You should verify whether this is the result of any action that you have performed.
NOTE - SSL has now strictly been superseded by transport layer
security (TLS), but the latter is still normally referred to using the older
The HTTP protocol includes its own mechanisms for
authenticating users, using various authentication schemes, including:
This is a very simple authentication mechanism that sends user credentials as a Base64-encoded string in a request header with each message.
This is a challenge-response mechanism and uses a version of the Windows NTLM protocol.
This is a challenge-response mechanism and uses MD5 checksums of a nonce with the user's credentials.