java.lang.Object java.io.InputStream org.apache.http.io.ChunkedInputStream
All Implemented Interfaces:
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 trailer CRLF chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF chunk-size = 1*HEX last-chunk = 1*("0") [ chunk-extension ] CRLF chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) trailer = *(entity-header CRLF)
The chunk-size field is a string of hex digits indicating the size of the chunk. The chunked encoding is ended by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field can be used to indicate which header fields are included in a trailer (see section 14.40).
A server using chunked transfer-coding in a response MUST NOT use the trailer for any header fields unless at least one of the following is true:
a)the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as described in section 14.39; or,
b)the server is the origin server for the response, the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable to the origin server) without receiving this metadata. In other words, the origin server is willing to accept the possibility that the trailer fields might be silently discarded along the path to the client.
This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have necessitated a possibly infinite buffer on the proxy.
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.
Sean- C. Sullivan
- href="mailto:mbowler@GargoyleSoftware.com">Mike Bowler
- href="mailto:oleg at ural.ru">Oleg Kalnichevski
|Method from org.apache.http.io.ChunkedInputStream Summary:|
|close, exhaustInputStream, getFooters, read, read, read|
|Methods from java.io.InputStream:|
|available, close, mark, markSupported, read, read, read, reset, skip|
|Methods from java.lang.Object:|
|clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait|
|Method from org.apache.http.io.ChunkedInputStream Detail:|
public void close() throws IOException
static void exhaustInputStream(InputStream inStream) throws IOException
Note that this function is intended as a non-public utility. This is a little weird, but it seemed silly to make a utility class for this one function, so instead it is just static and shared that way.
public Header getFooters()
public int read() throws IOException
Returns all the data in a chunked stream in coalesced form. A chunk is followed by a CRLF. The method returns -1 as soon as a chunksize of 0 is detected.
Trailer headers are read automcatically at the end of the stream and can be obtained with the getResponseFooters() method.
public int read(byte b) throws IOException
public int read(byte b, int off, int len) throws IOException