Network Working Group R. Fielding Request for Comments: 2616 ...

More documents

Recommendations

Info

message-body = entity-body| Transfer-Encoding MUST be used to indicate any transfer-codingsapplied by an application to ensure safe and proper transfer of themessage. Transfer-Encoding is a property of the message, not of theFielding, et al. Standards Track [Page 32]RFC 2616 HTTP/1.1 June 1999entity, and thus MAY be added or removed by any application along therequest/response chain. (However, section 3.6 places restrictions onwhen certain transfer-codings may be used.)The rules for when a message-body is allowed in a message differ forrequests and responses.The presence of a message-body in a request is signaled by theinclusion of a Content-Length or Transfer-Encoding header field inthe request's message-headers. A message-body MUST NOT be included ina request if the specification of the request method (section 5.1.1)does not allow sending an entity-body in requests. A server SHOULDread and forward a message-body on any request; if the request methoddoes not include defined semantics for an entity-body, then themessage-body SHOULD be ignored when handling the request.For response messages, whether or not a message-body is included witha message is dependent on both the request method and the responsestatus code (section 6.1.1). All responses to the HEAD request methodMUST NOT include a message-body, even though the presence of entityheaderfields might lead one to believe they do. All 1xx(informational), 204 (no content), and 304 (not modified) responsesMUST NOT include a message-body. All other responses do include amessage-body, although it MAY be of zero length.4.4 Message LengthThe transfer-length of a message is the length of the message-body asit appears in the message; that is, after any transfer-codings havebeen applied. When a message-body is included with a message, thetransfer-length of that body is determined by one of the following(in order of precedence):1.Any response message which "MUST NOT" include a message-body (suchas the 1xx, 204, and 304 responses and any response to a HEADrequest) is always terminated by the first empty line after theheader fields, regardless of the entity-header fields present in
the message.2.If a Transfer-Encoding header field (section 14.41) is present andhas any value other than "identity", then the transfer-length isdefined by use of the "chunked" transfer-coding (section 3.6),unless the message is terminated by closing the connection.3.If a Content-Length header field (section 14.13) is present, itsdecimal value in OCTETs represents both the entity-length and thetransfer-length. The Content-Length header field MUST NOT be sentif these two lengths are different (i.e., if a Transfer-EncodingFielding, et al. Standards Track [Page 33]RFC 2616 HTTP/1.1 June 1999header field is present). If a message is received with both aTransfer-Encoding header field and a Content-Length header field,the latter MUST be ignored.4.If the message uses the media type "multipart/byteranges", and theransfer-length is not otherwise specified, then this selfelimitingmedia type defines the transfer-length. This media typeUST NOT be used unless the sender knows that the recipient can arseit; the presence in a request of a Range header with ultiple byterangespecifiers from a 1.1 client implies that the lient can parsemultipart/byteranges responses.A range header might be forwarded by a 1.0 proxy that does notunderstand multipart/byteranges; in this case the server MUSTdelimit the message using methods defined in items 1,3 or 5 ofthis section.5.By the server closing the connection. (Closing the connectioncannot be used to indicate the end of a request body, since thatwould leave no possibility for the server to send back a response.)For compatibility with HTTP/1.0 applications, HTTP/1.1 requestscontaining a message-body MUST include a valid Content-Length headerfield unless the server is known to be HTTP/1.1 compliant. If arequest contains a message-body and a Content-Length is not given,the server SHOULD respond with 400 (bad request) if it cannotdetermine the length of the message, or with 411 (length required) ifit wishes to insist on receiving a valid Content-Length.All HTTP/1.1 applications that receive entities MUST accept the"chunked" transfer-coding (section 3.6), thus allowing this mechanismto be used for messages when the message length cannot be determined
Page 2: eferred to as "HTTP/1.1", and is an
Page 5 and 6: 12.1 Server-driven Negotiation ....
Page 7 and 8: 14.40 Trailer .....................
Page 9 and 10: 1.2 RequirementsThe key words "MUST
Page 12 and 13: Fielding, et al. Standards Track [P
Page 14 and 15: equest chain ----------------------
Page 16 and 17: Elements separated by a bar ("|") a
Page 18 and 19: HTTP/1.1 header field values can be
Page 20 and 21: An application that sends a request
Page 22 and 23: 3.2.3 URI ComparisonWhen comparing
Page 26 and 27: is not desirable and is discouraged
Page 28 and 29: CRLFchunk = chunk-size [ chunk-exte
Page 30 and 31: When in canonical form, media subty
Page 32 and 33: 3.9 Quality ValuesHTTP content nego
Page 34 and 35: RFC 2616 HTTP/1.1 June 1999HTTP/1.1
Page 38 and 39: in advance.Messages MUST NOT includ
Page 40 and 41: equested resource, and 501 (Not Imp
Page 42 and 43: names) MUST use the following rules
Page 44 and 45: values for the first digit:- 1xx: I
Page 48 and 49: how the transfer-length of a messag
Page 50 and 51: connection-token close.If either th
Page 52 and 53: idempotent (see section 9.1.2). Non
Page 54 and 55: compatibility with RFC 2068, a serv
Page 56 and 57: If at any point an error status is
Page 58 and 59: optional features implemented by th
Page 60 and 61: - Extending a database through an a
Page 62 and 63: intervention (or other means) on th
Page 64 and 65: 10.1.2 101 Switching ProtocolsThe s
Page 66 and 67: esponse MAY include new or updated
Page 70 and 71: The response MUST include the follo
Page 72 and 73: If the client is sending data, a se
Page 74 and 75: If the response could be unacceptab
Page 76 and 77: 10.4.15 414 Request-URI Too LongThe
Page 78 and 79: 10.5.5 504 Gateway TimeoutThe serve
Page 82 and 83: Caching would be useless if it did
Page 84 and 85: Warning (but without removing any e
Page 86 and 87:
If the user has overridden the basi
Page 88 and 89:
in the past. This means that the re
Page 90 and 91:
RFC 2616 HTTP/1.1 June 1999the time
Page 92 and 93:
simple:response_is_fresh = (freshne
Page 94 and 95:
match.In HTTP/1.1, a conditional re
Page 96 and 97:
validators or strong validators. Cl
Page 98 and 99:
- MAY send a weak entity tag instea
Page 100 and 101:
Unless specifically constrained by
Page 102 and 103:
Fielding, et al. Standards Track [P
Page 104 and 105:
warn-code 1xx, which are deleted ev
Page 106 and 107:
for the associated entity, its enti
Page 108 and 109:
- DELETE- POSTIn order to prevent d
Page 110 and 111:
The Accept request-header field can
Page 112 and 113:
image/jpeg = 0.5text/html;level=2 =
Page 114 and 115:
Note: If the request does not inclu
Page 116 and 117:
Accept-Ranges: bytesbut are not req
Page 118 and 119:
containing an Authorization field,
Page 120 and 121:
- Restrictions on what may be store
Page 122 and 123:
improve privacy in some cases, we c
Page 124 and 125:
Page 126 and 127:
must-revalidateBecause a cache MAY
Page 128 and 129:
understand.For example, consider a
Page 130 and 131:
new coding is known to be acceptabl
Page 132 and 133:
14.14 Content-LocationThe Content-L
Page 134 and 135:
Note: while the definition of Conte
Page 136 and 137:
server SHOULD return them in the or
Page 138 and 139:
Some origin server implementations
Page 140 and 141:
Expires = "Expires" ":" HTTP-dateAn
Page 142 and 143:
A client MUST include a Host header
Page 144 and 145:
een modified since the date given b
Page 146 and 147:
RFC 2616 HTTP/1.1 June 1999If none
Page 148 and 149:
14.29 Last-ModifiedThe Last-Modifie
Page 150 and 151:
MAY require that behavior be consis
Page 152 and 153:
yte-ranges-specifier = bytes-unit "
Page 154 and 155:
Content) instead of 200 (OK).- The
Page 156 and 157:
The TE request-header field indicat
Page 158 and 159:
Page 160 and 161:
a cache cannot determine from the r
Page 162 and 163:
SHOULD NOT, by default, forward the
Page 164 and 165:
this user agent behavior in mind.Re
Page 166 and 167:
designers and implementors be parti
Page 168 and 169:
strongly correlated to the membersh
Page 170 and 171:
serious security considerations. Co
Page 172 and 173:
The HTTP protocol has evolved consi
Page 174 and 175:
Protocol -- HTTP/1.0", RFC 1945, Ma
Page 176 and 177:
Implementation and Analysis", RFC 1
Page 178 and 179:
University of California, IrvineIrv
Page 180 and 181:
Page 182 and 183:
Notes:1) Additional CRLFs may prece
Page 184 and 185:
full compliance with the MIME proto
Page 186 and 187:
ead chunk-size and CRLF}read entity
Page 188 and 189:
- understand any valid response in
Page 190 and 191:
CREATE had a race that required an
Page 192 and 193:
also needed to be a general header,
Page 194:
show all

Network Working Group R. Fielding Request for Comments: 2616 ...

Create successful ePaper yourself

Delete template?

Save as template?