HTTP协议为什么获取不到文件的size？

neubuffalo

HTTp协议在从远端返回的响应头中为什么有时候没有content_length信息呢？

asert

Post by neubuffalo;1851505
HTTp协议在从远端返回的响应头中为什么有时候没有content_length信息呢？

没有content_length就说明直到对方关闭连接才表示数据传输完毕；

jeff_yecn

有时候长度在开始发送头的时候还不能确定。比如 php 动态网页。因此，长度信息是个可选的。

asert

Post by jeff_yecn;1851656
有时候长度在开始发送头的时候还不能确定。比如 php 动态网页。因此，长度信息是个可选的。

你说的这个就要在http头部包含transfer-coding="chunked"头域，具体看协议

1. 
   
2. 3.6 Transfer Codings
   
3. Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding is a property of the message, not of the original entity.
   
4.        transfer-coding         = "chunked" | transfer-extension
   
5.        transfer-extension      = token *( ";" parameter )
   
6. 
   
7. Parameters are in the form of attribute/value pairs.
   
8.        parameter               = attribute "=" value
   
9.        attribute               = token
   
10.        value                   = token | quoted-string
    
11. 
    
12. All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (section 14.39) and in the Transfer-Encoding header field (section 14.41).
    
13. Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include "chunked", unless the message is terminated by closing the connection. When the "chunked" transfer- coding is used, it MUST be the last transfer-coding applied to the message-body. The "chunked" transfer-coding MUST NOT be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message (section 4.4).
    
14. Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME [7], which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty in determining the exact body length (section 7.2.2), or the desire to encrypt data over a shared transport.
    
15. The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (section 3.6.1), "identity" (section 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5).
    
16. New transfer-coding value tokens SHOULD be registered in the same way as new content-coding value tokens (section 3.5).
    
17. A server which receives an entity-body with a transfer-coding it does not understand SHOULD return 501 (Unimplemented), and close the connection. A server MUST NOT send transfer-codings to an HTTP/1.0 client.
    
18. 3.6.1 Chunked Transfer Coding
    
19. 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.
    
20.        Chunked-Body   = *chunk
    
21.                         last-chunk
    
22.                         trailer
    
23.                         CRLF
    
24. 
    
25.        chunk          = chunk-size [ chunk-extension ] CRLF
    
26.                         chunk-data CRLF
    
27.        chunk-size     = 1*HEX
    
28.        last-chunk     = 1*("0") [ chunk-extension ] CRLF
    
29. 
    
30.        chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
    
31.        chunk-ext-name = token
    
32.        chunk-ext-val  = token | quoted-string
    
33.        chunk-data     = chunk-size(OCTET)
    
34.        trailer        = *(entity-header CRLF)
    
35. 
    
36. 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.
    
37. 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).
    
38. 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:
    
39. 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,
    
40. 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.
    
41. 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.
    
42. An example process for decoding a Chunked-Body is presented in appendix 19.4.6.
    
43. All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding, and MUST ignore chunk-extension extensions they do not understand.
    

复制代码