HTTP Request: Difference between revisions
No edit summary |
No edit summary |
||
Line 95: | Line 95: | ||
<font color=red> | <font color=red> | ||
The request may transfer an entity. An entity consists of entity-header fields and an entity-body | |||
</font> | |||
==HTTP Entity Header Fields== | |||
===Allow=== | |||
===Content-Encoding=== | |||
===Content-Language=== | |||
===Content-Length=== | |||
===Content-Location=== | |||
===Content-MD5=== | |||
===Content-Range=== | |||
===Content-Type=== | |||
===Expires=== | |||
===Last-Modified=== | |||
==HTTP Request Entity Body== | |||
<font color=red> | |||
The entity-body (if any) sent with the HTTP request or response is in a format and encoding defined by the [entity-header fields|HTTP#HTTPEntityHeaderFields]. | The entity-body (if any) sent with the HTTP request or response is in a format and encoding defined by the [entity-header fields|HTTP#HTTPEntityHeaderFields]. | ||
</font> | </font> |
Revision as of 03:35, 22 April 2016
Internal
Overview
A HTTP request consists of a header section, followed by a blank line, followed by the request body.
An example of a header section follows:
GET /intro.html HTTP/1.1 User-Agent: Mozilla/4.0 Accept: image/gif, image/jpeg, text/*, */*
The first line of the request specifies the method, the URL of the document and the version of the HTML protocol it is using. The next lines contain optional header information, that carry extra information about the request. After the headers, the client sends a blank line to indicate the end of the header section.
The HTTP Method
The HTTP Methods are: GET, POST, PUT, HEAD, DELETE, TRACE, OPTIONS and CONNECT. The most common are GET and POST.
HTTP methods in RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
GET
The GET method is designed for getting information, such as a document, a chart or the result from a database query. The GET method can include as part of the request some of its own information that better describes what to get. This information is passed as a query string: a sequence of characters appended to the request URL. Placing the extra information in the URL in this way allows the page to be bookmarked or emailed like any other. Because GET requests theoretically shouldn't need to send large amounts of information, some servers limit the length of URL's and query string to about 240 characters.
GET is read-only. It is idempotent (repeated application does not modify the resource except the first time) and safe (does not change the state of the resource).
POST
The POST method is designed for posting information. A POST request passes all its data, of unlimited length, directly over the socket connection as part of its HTTP request body. The exchange is invisible to the client, the URL doesn't change at all, so POST requests cannot be bookmarked.
The data can be actually encoded over the connection using different encoding types:
- application/x-www-form-urlencoded - this is what HttpClient uses by default.
- multipart/form-data
POST is non-idempotent and unsafe operation, each POST method is allowed to modify the resource in an unique way. Information may or may not be sent information with the requests. Information may or may not be received with the response.
PUT
The PUT request instructs the server to store the message body sent with the request under the location provided in the HTTP message. Usually modeled as an insert or update. It is idempotent.
DELETE
The DELETE request is used to remove resources. It is idempotent.
HEAD
Similar to GET, except that instead of returning a response body, it only returns a response code and headers.
OPTIONS
Used to request information about communication options of the resource. Allows the client to determine the capabilities of the server, without triggering any resource action or retrieval.
HTTP Request Headers
The HTTP request headers are present in the HTTP request itself, as a list of strings, terminated by an empty line. The header section can be (or not) followed by a body. The header format is governed by RFC822.
From RFC822: Each header field can be viewed as a single, logical line of ASCII characters, comprising a field-name, followed by a colon (":") and a field-body. For convenience, the field-body portion of this conceptual entity can be split into a multiple-line representation (folding). The field name must be composed of printable ASCII characters (i.e., characters that have values between 33 and 126, except colon).
More: http://www.faqs.org/rfcs/rfc822.html
HTTP request headers can be interacted with from an Apache httpclient method using HttpMethod.getRequestHeaders(). HTTP request headers can be accessed from a servlet request using HttpServletRequest.getHeader(String name).
Header Case Independence
When working with header names, capitalization does not matter. Case is to be ignored. For example, the field-names "From", "FROM", "from", and even "FroM" are semantically equal and should all be treated identically.
Accept
HTTP Query String Parameters
HTTP query string parameters are encoded in the URL and can be accessed from a servlet using: HttpServletRequest.getParameter(String name)
Example:
http://localhost/something?a=100&b=200
"a" and "b" are query string parameters.
HTTP Method Parameters
TODO
The HTTP Request Body
The request may transfer an entity. An entity consists of entity-header fields and an entity-body
HTTP Entity Header Fields
Allow
Content-Encoding
Content-Language
Content-Length
Content-Location
Content-MD5
Content-Range
Content-Type
Expires
Last-Modified
HTTP Request Entity Body
The entity-body (if any) sent with the HTTP request or response is in a format and encoding defined by the [entity-header fields|HTTP#HTTPEntityHeaderFields].