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 32 package org.apache.http.impl.entity; 33 34 import org.apache.http.Header; 35 import org.apache.http.HeaderElement; 36 import org.apache.http.HttpException; 37 import org.apache.http.HttpMessage; 38 import org.apache.http.ParseException; 39 import org.apache.http.ProtocolException; 40 import org.apache.http.entity.ContentLengthStrategy; 41 import org.apache.http.params.HttpParams; 42 import org.apache.http.params.CoreProtocolPNames; 43 import 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 186 public class LaxContentLengthStrategy implements ContentLengthStrategy { 187 LaxContentLengthStrategy()188 public LaxContentLengthStrategy() { 189 super(); 190 } 191 determineLength(final HttpMessage message)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