1/*
2 * $HeadURL: http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/module-main/src/main/java/org/apache/http/impl/entity/LaxContentLengthStrategy.java $
3 * $Revision: 576073 $
4 * $Date: 2007-09-16 03:53:13 -0700 (Sun, 16 Sep 2007) $
5 *
6 * ====================================================================
7 * Licensed to the Apache Software Foundation (ASF) under one
8 * or more contributor license agreements.  See the NOTICE file
9 * distributed with this work for additional information
10 * regarding copyright ownership.  The ASF licenses this file
11 * to you under the Apache License, Version 2.0 (the
12 * "License"); you may not use this file except in compliance
13 * with the License.  You may obtain a copy of the License at
14 *
15 *   http://www.apache.org/licenses/LICENSE-2.0
16 *
17 * Unless required by applicable law or agreed to in writing,
18 * software distributed under the License is distributed on an
19 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
20 * KIND, either express or implied.  See the License for the
21 * specific language governing permissions and limitations
22 * under the License.
23 * ====================================================================
24 *
25 * This software consists of voluntary contributions made by many
26 * individuals on behalf of the Apache Software Foundation.  For more
27 * information on the Apache Software Foundation, please see
28 * <http://www.apache.org/>.
29 *
30 */
31
32package org.apache.http.impl.entity;
33
34import org.apache.http.Header;
35import org.apache.http.HeaderElement;
36import org.apache.http.HttpException;
37import org.apache.http.HttpMessage;
38import org.apache.http.ParseException;
39import org.apache.http.ProtocolException;
40import org.apache.http.entity.ContentLengthStrategy;
41import org.apache.http.params.HttpParams;
42import org.apache.http.params.CoreProtocolPNames;
43import org.apache.http.protocol.HTTP;
44
45/**
46 * The lax implementation of the content length strategy.
47 * <p>
48 * This strategy conforms to the entity transfer rules outlined in
49 * <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec4.4">Section 4.4</a>,
50 * <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6">Section 3.6</a>,
51 * <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.41">Section 14.41</a>
52 * and <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec14.13">Section 14.13</a>
53 * of <a href="http://www.w3.org/Protocols/rfc2616/rfc2616.txt">RFC 2616</a>, but is lenient
54 * about unsupported transfer codecs and malformed content-length headers.
55 * </p>
56 * <h>4.4 Message Length</h>
57 * <p>
58 * The transfer-length of a message is the length of the message-body as it appears in the
59 * message; that is, after any transfer-codings have been applied. When a message-body is
60 * included with a message, the transfer-length of that body is determined by one of the
61 * following (in order of precedence):
62 * </p>
63 * <p>
64 * 1.Any response message which "MUST NOT" include a message-body (such as the 1xx, 204,
65 * and 304 responses and any response to a HEAD request) is always terminated by the first
66 * empty line after the header fields, regardless of the entity-header fields present in the
67 * message.
68 * </p>
69 * <p>
70 * 2.If a Transfer-Encoding header field (section 14.41) is present and has any value other
71 * than "identity", then the transfer-length is defined by use of the "chunked" transfer-
72 * coding (section 3.6), unless the message is terminated by closing the connection.
73 * </p>
74 * <p>
75 * 3.If a Content-Length header field (section 14.13) is present, its decimal value in
76 * OCTETs represents both the entity-length and the transfer-length. The Content-Length
77 * header field MUST NOT be sent if these two lengths are different (i.e., if a
78 * Transfer-Encoding
79 * </p>
80 * <pre>
81 *    header field is present). If a message is received with both a
82 *    Transfer-Encoding header field and a Content-Length header field,
83 *    the latter MUST be ignored.
84 * </pre>
85 * <p>
86 * 4.If the message uses the media type "multipart/byteranges", and the ransfer-length is not
87 * otherwise specified, then this self- elimiting media type defines the transfer-length.
88 * This media type UST NOT be used unless the sender knows that the recipient can arse it; the
89 * presence in a request of a Range header with ultiple byte- range specifiers from a 1.1
90 * client implies that the lient can parse multipart/byteranges responses.
91 * </p>
92 * <pre>
93 *     A range header might be forwarded by a 1.0 proxy that does not
94 *     understand multipart/byteranges; in this case the server MUST
95 *     delimit the message using methods defined in items 1,3 or 5 of
96 *     this section.
97 * </pre>
98 * <p>
99 * 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 * @deprecated Please use {@link java.net.URL#openConnection} instead.
182 *     Please visit <a href="http://android-developers.blogspot.com/2011/09/androids-http-clients.html">this webpage</a>
183 *     for further details.
184 */
185@Deprecated
186public class LaxContentLengthStrategy implements ContentLengthStrategy {
187
188    public LaxContentLengthStrategy() {
189        super();
190    }
191
192    public long determineLength(final HttpMessage message) throws HttpException {
193        if (message == null) {
194            throw new IllegalArgumentException("HTTP message may not be null");
195        }
196
197        HttpParams params = message.getParams();
198        boolean strict = params.isParameterTrue(CoreProtocolPNames.STRICT_TRANSFER_ENCODING);
199
200        Header transferEncodingHeader = message.getFirstHeader(HTTP.TRANSFER_ENCODING);
201        Header contentLengthHeader = message.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 && encoding.length() > 0
218                        && !encoding.equalsIgnoreCase(HTTP.CHUNK_CODING)
219                        && !encoding.equalsIgnoreCase(HTTP.IDENTITY_CODING)) {
220                        throw new ProtocolException("Unsupported transfer encoding: " + encoding);
221                    }
222                }
223            }
224            // The chunked encoding must be the last one applied RFC2616, 14.41
225            int len = encodings.length;
226            if (HTTP.IDENTITY_CODING.equalsIgnoreCase(transferEncodingHeader.getValue())) {
227                return IDENTITY;
228            } else if ((len > 0) && (HTTP.CHUNK_CODING.equalsIgnoreCase(
229                    encodings[len - 1].getName()))) {
230                return CHUNKED;
231            } else {
232                if (strict) {
233                    throw new ProtocolException("Chunk-encoding must be the last one applied");
234                }
235                return IDENTITY;
236            }
237        } else if (contentLengthHeader != null) {
238            long contentlen = -1;
239            Header[] headers = message.getHeaders(HTTP.CONTENT_LEN);
240            if (strict && headers.length > 1) {
241                throw new ProtocolException("Multiple content length headers");
242            }
243            for (int i = headers.length - 1; i >= 0; i--) {
244                Header header = headers[i];
245                try {
246                    contentlen = Long.parseLong(header.getValue());
247                    break;
248                } catch (NumberFormatException e) {
249                    if (strict) {
250                        throw new ProtocolException("Invalid content length: " + header.getValue());
251                    }
252                }
253                // See if we can have better luck with another header, if present
254            }
255            if (contentlen >= 0) {
256                return contentlen;
257            } else {
258                return IDENTITY;
259            }
260        } else {
261            return IDENTITY;
262        }
263    }
264
265}
266