|Home >> All >> org >> apache >> [ http Javadoc ]|
org.apache.http: Javadoc index of package org.apache.http.
org.apache.http.impl.entity: Default implementations for interfaces in org.apache.http.
org.apache.http.util: The core interfaces and classes of the HTTP components.
DefaultEntityDeserializer: Default implementation of an entity generator. This entity generator comforms to the entity transfer rules outlined in the Section 4.4 , Section 3.6 , Section 14.41 and Section 14.13 of RFC 2616 4.4 Message Length The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence): 1.Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and ...
ChunkedInputStream: This class implements chunked transfer coding as described in the Section 3.6.1 of RFC 2616 . It transparently coalesces chunks of a HTTP stream that uses chunked transfer coding. 3.6.1 Chunked Transfer Coding The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer containing entity-header fields. This allows dynamically produced content to be transferred along with the information necessary for the recipient to verify that it has received the full message. Chunked-Body = *chunk last-chunk ...
ChunkedOutputStream: This class implements chunked transfer coding as described in the Section 3.6.1 of RFC 2616 . Writes are buffered to an internal buffer (2048 default size). Chunks are guaranteed to be at least as large as the buffer size (except for the last chunk). 3.6.1 Chunked Transfer Coding The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer containing entity-header fields. This allows dynamically produced content to be transferred along with the information necessary for the recipient to verify ...
NameValuePair: A simple class encapsulating an attribute/value pair. This class comforms to the generic grammar and formatting rules outlined in the Section 2.2 and Section 3.6 of RFC 2616 2.2 Basic Rules The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986. OCTET = CHAR = UPALPHA = LOALPHA = ALPHA = UPALPHA | LOALPHA DIGIT = CTL = CR = LF = SP = HT = = Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used ...
HttpEntity: An entity that can be sent or received with an HTTP message. Entities can be found in some requests and in responses , where they are optional. In some places, the JavaDoc distinguishes three kinds of entities, depending on where their content 55 originates: streamed : The content is received from a stream, or generated on the fly. In particular, this category includes entities being received from a connection . Streamed 55 entities are generally not repeatable 55 . self-contained : The content is in memory or obtained by means that are independent from a connection or other entity. Self-contained ...
ContentLengthInputStream: This class cuts the wrapped InputStream off after a specified number of bytes. Note that this class NEVER closes the underlying stream, even when close gets called. Instead, it will read until the "end" of its chunking on close, which allows for the seamless invocation of subsequent HTTP 1.1 calls, while not requiring the client to remember to read the entire contents of the response. Implementation note: Choices abound. One approach would pass through the InputStream.mark(int) > InputStream.mark(int) 55 and InputStream.reset() > InputStream.reset() 55 calls to the underlying stream. That's tricky, ...
HeaderElement: One element of an HTTP header's value. Some HTTP headers (such as the set-cookie header) have values that can be decomposed into multiple elements. Such headers must be in the following form: header = [ element ] *( "," [ element ] ) element = name [ "=" [ value ] ] *( ";" [ param ] ) param = name [ "=" [ value ] ] name = token value = ( token | quoted-string ) token = 1*<any char except "=", ",", ";", <"> and white space> quoted-string = <"> *( text | quoted-char ) <"> text = any char except <"> quoted-char = "\" char Any amount of white space is allowed between any ...
HttpVersion: HTTP version, as specified in RFC 2616. HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The <minor> number is incremented when the changes made to the protocol ...
Header: Represents an HTTP header field. The HTTP header fields follow the same generic format as that given in Section 3.1 of RFC 822. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The field value MAY be preceded by any amount of LWS, though a single SP is preferred. message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string>
StatusLine: Represents a Status-Line as returned from a HTTP server. RFC2616 states the following regarding the Status-Line: 6.1 Status-Line The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF This class is immutable and is inherently thread safe.
SocketFactory: A factory for creating Sockets. Both Object.equals() 55 and Object.hashCode() 55 should be overridden appropriately. Protocol socket factories are used to uniquely identify Protocol s and HostConfiguration s, and equals() and hashCode() are required for the correct operation of some connection managers.
Scheme: A class to encapsulate the specifics of a protocol scheme. This class also provides the ability to customize the set and characteristics of the schemes used. One use case for modifying the default set of protocols would be to set a custom SSL socket factory. This would look something like the following: Scheme myHTTPS = new Scheme( "https", new MySSLSocketFactory(), 443 ); Scheme.registerScheme( "https", myHTTPS );
HttpEntityWrapper: Base class for wrapping entities. Keeps a wrappedEntity 55 and delegates all calls to it. Implementations of wrapping entities can derive from this class and need to override only those methods that should not be delegated to the wrapped entity.
HttpContext: A context for executing a request. The context is used to tie together the request, the response, and optional application data. It is also used for internal data. Attribute names starting with the prefix "http." are reserved 55 for internal data.
BufferedHttpEntity: A wrapping entity that buffers it content if necessary. The buffered entity is always repeatable. If the wrapped entity is repeatable itself, calls are passed through. If the wrapped entity is not repeatable, the content is read into a buffer once and provided from there as often as required.
HttpParams: This interface represents a collection of HTTP protocol parameters. Protocol parameters may be linked together to form a hierarchy. If a particular parameter value has not been explicitly defined in the collection itself, its value will be drawn from the parent collection of parameters.
DefaultHttpParams: This class represents a collection of HTTP protocol parameters. Protocol parameters may be linked together to form a hierarchy. If a particular parameter value has not been explicitly defined in the collection itself, its value will be drawn from the parent collection of parameters.
HttpRequestRetryHandler: A handler for determining if an HttpRequest should be retried after a recoverable exception during execution. Classes implementing this interface must synchronize access to shared data as methods of this interfrace may be executed from multiple threads
HttpConnectionParams: This class implements an adaptor around the HttpParams interface to simplify manipulation of the HTTP connection specific parameters.
HttpProtocolParams: This class implements an adaptor around the HttpParams interface to simplify manipulation of the HTTP protocol specific parameters.
RequestLine: The first line of an HttpRequest . It contains the method, URI, and HTTP version of the request. For details, see RFC 2616.
SecureSocketFactory: A SocketFactory for secure sockets (SSL/TLS). See there for things to consider when implementing a socket factory.
DateUtils: A utility class for parsing and formatting HTTP dates as used in cookies and other headers. This class handles dates as defined by RFC 2616 section 3.3.1 as well as some other common non-standard formats.
AbstractHttpEntity: Abstract base class for entities. Provides the commonly used attributes for streamed and self-contained implementations of HttpEntity .
LangUtils: A set of utility methods to help produce consistent equals 55 and hashCode 55 methods.