001: /*
002: * $HeadURL: https://svn.apache.org/repos/asf/httpcomponents/httpcore/tags/4.0-beta1/module-main/src/main/java/org/apache/http/impl/entity/LaxContentLengthStrategy.java $
003: * $Revision: 576073 $
004: * $Date: 2007-09-16 12:53:13 +0200 (Sun, 16 Sep 2007) $
005: *
006: * ====================================================================
007: * Licensed to the Apache Software Foundation (ASF) under one
008: * or more contributor license agreements. See the NOTICE file
009: * distributed with this work for additional information
010: * regarding copyright ownership. The ASF licenses this file
011: * to you under the Apache License, Version 2.0 (the
012: * "License"); you may not use this file except in compliance
013: * with the License. You may obtain a copy of the License at
014: *
015: * http://www.apache.org/licenses/LICENSE-2.0
016: *
017: * Unless required by applicable law or agreed to in writing,
018: * software distributed under the License is distributed on an
019: * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
020: * KIND, either express or implied. See the License for the
021: * specific language governing permissions and limitations
022: * under the License.
023: * ====================================================================
024: *
025: * This software consists of voluntary contributions made by many
026: * individuals on behalf of the Apache Software Foundation. For more
027: * information on the Apache Software Foundation, please see
028: * <http://www.apache.org/>.
029: *
030: */
031:
032: package org.apache.http.impl.entity;
033:
034: import org.apache.http.Header;
035: import org.apache.http.HeaderElement;
036: import org.apache.http.HttpException;
037: import org.apache.http.HttpMessage;
038: import org.apache.http.ParseException;
039: import org.apache.http.ProtocolException;
040: import org.apache.http.entity.ContentLengthStrategy;
041: import org.apache.http.params.HttpParams;
042: import org.apache.http.params.CoreProtocolPNames;
043: import org.apache.http.protocol.HTTP;
044:
045: /**
046: * The lax implementation of the content length strategy.
047: * <p>
048: * This strategy conforms to the entity transfer rules outlined in
049: * <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec4.4">Section 4.4</a>,
050: * <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6">Section 3.6</a>,
051: * <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.41">Section 14.41</a>
052: * and <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec14.13">Section 14.13</a>
053: * of <a href="http://www.w3.org/Protocols/rfc2616/rfc2616.txt">RFC 2616</a>, but is lenient
054: * about unsupported transfer codecs and malformed content-length headers.
055: * </p>
056: * <h>4.4 Message Length</h>
057: * <p>
058: * The transfer-length of a message is the length of the message-body as it appears in the
059: * message; that is, after any transfer-codings have been applied. When a message-body is
060: * included with a message, the transfer-length of that body is determined by one of the
061: * following (in order of precedence):
062: * </p>
063: * <p>
064: * 1.Any response message which "MUST NOT" include a message-body (such as the 1xx, 204,
065: * and 304 responses and any response to a HEAD request) is always terminated by the first
066: * empty line after the header fields, regardless of the entity-header fields present in the
067: * message.
068: * </p>
069: * <p>
070: * 2.If a Transfer-Encoding header field (section 14.41) is present and has any value other
071: * than "identity", then the transfer-length is defined by use of the "chunked" transfer-
072: * coding (section 3.6), unless the message is terminated by closing the connection.
073: * </p>
074: * <p>
075: * 3.If a Content-Length header field (section 14.13) is present, its decimal value in
076: * OCTETs represents both the entity-length and the transfer-length. The Content-Length
077: * header field MUST NOT be sent if these two lengths are different (i.e., if a
078: * Transfer-Encoding
079: * </p>
080: * <pre>
081: * header field is present). If a message is received with both a
082: * Transfer-Encoding header field and a Content-Length header field,
083: * the latter MUST be ignored.
084: * </pre>
085: * <p>
086: * 4.If the message uses the media type "multipart/byteranges", and the ransfer-length is not
087: * otherwise specified, then this self- elimiting media type defines the transfer-length.
088: * This media type UST NOT be used unless the sender knows that the recipient can arse it; the
089: * presence in a request of a Range header with ultiple byte- range specifiers from a 1.1
090: * client implies that the lient can parse multipart/byteranges responses.
091: * </p>
092: * <pre>
093: * A range header might be forwarded by a 1.0 proxy that does not
094: * understand multipart/byteranges; in this case the server MUST
095: * delimit the message using methods defined in items 1,3 or 5 of
096: * this section.
097: * </pre>
098: * <p>
099: * 5.By the server closing the connection. (Closing the connection cannot be used to indicate
100: * the end of a request body, since that would leave no possibility for the server to send back
101: * a response.)
102: * </p>
103: * <p>
104: * For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body
105: * MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1
106: * compliant. If a request contains a message-body and a Content-Length is not given, the
107: * server SHOULD respond with 400 (bad request) if it cannot determine the length of the
108: * message, or with 411 (length required) if it wishes to insist on receiving a valid
109: * Content-Length.
110: * </p>
111: * <p>All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer-coding
112: * (section 3.6), thus allowing this mechanism to be used for messages when the message
113: * length cannot be determined in advance.
114: * </p>
115: * <h>3.6 Transfer Codings</h>
116: * <p>
117: * Transfer-coding values are used to indicate an encoding transformation that
118: * has been, can be, or may need to be applied to an entity-body in order to ensure
119: * "safe transport" through the network. This differs from a content coding in that
120: * the transfer-coding is a property of the message, not of the original entity.
121: * </p>
122: * <pre>
123: * transfer-coding = "chunked" | transfer-extension
124: * transfer-extension = token *( ";" parameter )
125: * </pre>
126: * <p>
127: * Parameters are in the form of attribute/value pairs.
128: * </p>
129: * <pre>
130: * parameter = attribute "=" value
131: * attribute = token
132: * value = token | quoted-string
133: * </pre>
134: * <p>
135: * All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in
136: * the TE header field (section 14.39) and in the Transfer-Encoding header field (section 14.41).
137: * </p>
138: * <p>
139: * Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST
140: * include "chunked", unless the message is terminated by closing the connection. When the
141: * "chunked" transfer-coding is used, it MUST be the last transfer-coding applied to the
142: * message-body. The "chunked" transfer-coding MUST NOT be applied more than once to a
143: * message-body. These rules allow the recipient to determine the transfer-length of the
144: * message (section 4.4).
145: * </p>
146: * <h>14.41 Transfer-Encoding</h>
147: * <p>
148: * The Transfer-Encoding general-header field indicates what (if any) type of transformation has
149: * been applied to the message body in order to safely transfer it between the sender and the
150: * recipient. This differs from the content-coding in that the transfer-coding is a property of
151: * the message, not of the entity.
152: * </p>
153: * <pre>
154: * Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
155: * </pre>
156: * <p>
157: * If multiple encodings have been applied to an entity, the transfer- codings MUST be listed in
158: * the order in which they were applied. Additional information about the encoding parameters
159: * MAY be provided by other entity-header fields not defined by this specification.
160: * </p>
161: * <h>14.13 Content-Length</h>
162: * <p>
163: * The Content-Length entity-header field indicates the size of the entity-body, in decimal
164: * number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of
165: * the entity-body that would have been sent had the request been a GET.
166: * </p>
167: * <pre>
168: * Content-Length = "Content-Length" ":" 1*DIGIT
169: * </pre>
170: * <p>
171: * Applications SHOULD use this field to indicate the transfer-length of the message-body,
172: * unless this is prohibited by the rules in section 4.4.
173: * </p>
174: *
175: * @author <a href="mailto:oleg at ural.ru">Oleg Kalnichevski</a>
176: *
177: * @version $Revision: 576073 $
178: *
179: * @since 4.0
180: */
181: public class LaxContentLengthStrategy implements ContentLengthStrategy {
182:
183: public LaxContentLengthStrategy() {
184: super ();
185: }
186:
187: public long determineLength(final HttpMessage message)
188: throws HttpException {
189: if (message == null) {
190: throw new IllegalArgumentException(
191: "HTTP message may not be null");
192: }
193:
194: HttpParams params = message.getParams();
195: boolean strict = params
196: .isParameterTrue(CoreProtocolPNames.STRICT_TRANSFER_ENCODING);
197:
198: Header transferEncodingHeader = message
199: .getFirstHeader(HTTP.TRANSFER_ENCODING);
200: Header contentLengthHeader = message
201: .getFirstHeader(HTTP.CONTENT_LEN);
202: // We use Transfer-Encoding if present and ignore Content-Length.
203: // RFC2616, 4.4 item number 3
204: if (transferEncodingHeader != null) {
205: HeaderElement[] encodings = null;
206: try {
207: encodings = transferEncodingHeader.getElements();
208: } catch (ParseException px) {
209: throw new ProtocolException(
210: "Invalid Transfer-Encoding header value: "
211: + transferEncodingHeader, px);
212: }
213: if (strict) {
214: // Currently only chunk and identity are supported
215: for (int i = 0; i < encodings.length; i++) {
216: String encoding = encodings[i].getName();
217: if (encoding != null
218: && encoding.length() > 0
219: && !encoding
220: .equalsIgnoreCase(HTTP.CHUNK_CODING)
221: && !encoding
222: .equalsIgnoreCase(HTTP.IDENTITY_CODING)) {
223: throw new ProtocolException(
224: "Unsupported transfer encoding: "
225: + encoding);
226: }
227: }
228: }
229: // The chunked encoding must be the last one applied RFC2616, 14.41
230: int len = encodings.length;
231: if (HTTP.IDENTITY_CODING
232: .equalsIgnoreCase(transferEncodingHeader.getValue())) {
233: return IDENTITY;
234: } else if ((len > 0)
235: && (HTTP.CHUNK_CODING
236: .equalsIgnoreCase(encodings[len - 1]
237: .getName()))) {
238: return CHUNKED;
239: } else {
240: if (strict) {
241: throw new ProtocolException(
242: "Chunk-encoding must be the last one applied");
243: }
244: return IDENTITY;
245: }
246: } else if (contentLengthHeader != null) {
247: long contentlen = -1;
248: Header[] headers = message.getHeaders(HTTP.CONTENT_LEN);
249: if (strict && headers.length > 1) {
250: throw new ProtocolException(
251: "Multiple content length headers");
252: }
253: for (int i = headers.length - 1; i >= 0; i--) {
254: Header header = headers[i];
255: try {
256: contentlen = Long.parseLong(header.getValue());
257: break;
258: } catch (NumberFormatException e) {
259: if (strict) {
260: throw new ProtocolException(
261: "Invalid content length: "
262: + header.getValue());
263: }
264: }
265: // See if we can have better luck with another header, if present
266: }
267: if (contentlen >= 0) {
268: return contentlen;
269: } else {
270: return IDENTITY;
271: }
272: } else {
273: return IDENTITY;
274: }
275: }
276:
277: }
|