wiki:HTTPFeatures

The table below is derived from  this one which was compiled by  Squid developer Robert Collins.

IDTypeSectionDescriptionStatus
1REQUIRED2.1handle implied LWS = [CRLF] 1*( SP | HT )
2REQUIRED2.2fold CRLF in headers into one long header before interpreting
3MUST3.1parse HTTP-Version as two multi-digit integers
4SHOULD3.1send HTTP/1.1 in messages once we are conditionally compilent
5MUST3.1send HTTP/1.1 in messages that are not compatible with HTTP/1.0
6MUST NOT3.1send HTTP versions greater than that of squid itself. (squid will be 1.1 when and only when it is conditionally compliant with rfc 2616
7MUST3.1"downgrade requests from greater than squid supports to what squid supports, return an error, or switch to tunnel behaviour"
8MUST3.1upgrade client requests to the highest version of HTTP supported by squid.
9MUST3.1"respond to old client requests with HTTP in the same major version. Ie a 1.x client must get a 1.x reponse, regardless if squid is a 2.x proxy by that point"
10MUST3.2.1handle the URI of any resource served out (read proxied)
11SHOULD3.2.1handle unbounded length URI's if we allow long GET requests
12SHOULD3.2.1return 414 for URI's longer than we can actually handle
13SHOULD3.2.2avoid using ip address's in generated URL's
14MUST3.2.2add / to http urls that have no abs_path; and if generating requests include the /
15MUST NOT3.2.2change the hostname in a request with a FQDN in it
16MAY3.2.2add squids domain to the hostname that are not fully qualified in requests received by squid
17SHOULD3.2.3compare URI's by case-sensitive octet-by-octet comparioson of the entire URI.
18MUST3.2.3compare hostnames in URI's case-insensitively
19MUST3.2.3compare scheme names in URI's case-insensitively
20MUST3.2.3match % HEX HEX encoded characters with those outside the reserved and unsafe sets when comparing URI's
21MUST3.3.1handle the three date formats of HTTP/1.0
22MUST3.3.1only generate dates in rfc 1123 format
23MUST3.3.1generate all dates in GMT (UTC) time.
24MUST3.3.1assume GMT time when reading asctime format
25MUST3.3.1not add LWS to the HTTP-date format other than that specifically included in the grammer
26MUST3.4specify the mapping assocaited with a MIME character set name when using MIME character sets
27SHOULD3.4limit the use of MIME character sets to IANA registry defined character sets
28MAY3.4.1include a charset parameter even when the charset is ISO-8559-1
29SHOULD3.4.1include a charset parameter even when the charset is ISO-8559-1 when we know we will not confuse the client
30MUST3.4.1for the 'client' respect the charset label provided by the sender.
31SHOULD NOT3.5create responses with Content-Encoding: identity
32SHOULD3.5register new content-coding value tokens with IANA
33SHOULD3.5make publicly available specifications for new content-coding value tokens which conform to the purpose of content coding as per section 3.5
34MUST3.6"when a transfer-coding is applied, include ""chunked"" in the set of transfer codings unless the message is terminated by closing the connection."
35MUST NOT3.6"applied ""chunked"" more than once to a message-body"
36SHOULD3.6register new transfer-encodings with IANA (as per section 3.5 for content-codings
37SHOULD3.6return 501 and close the connection when client entity-bodies are received that squid doesn't understand the transfer-codings of.
38MUST NOT3.6send transfer-codings (TE or Transfer-Encoding headers) to HTTP/1.0 clients
39OPTIONAL3.6.1send a trailer after sending chunked transfer encoded messages
40MUST NOT3.6.1"put headers in the trailer unless a) the request included a TE header that indicates trailers is acceptable in the transfercoding (see 14.39) or b) the server is the origin, (and paraphrasing) the trailers are not needed to use the response)"
41MUST3.6.1"understand ""chunked"" transfer-coding"
42MUST3.6.1ignore chunk-extensions not understood
43MUST NOT3.7"use LWS between the type and sub type in media-types, or between attribute and values"
44SHOULD3.7when sending to older applications (< HTTP/1.1) only use media types when required by the type/subtype definition
45MUST3.7.1"represent entity-bodies in canonical media-type form (except ""text"" types)."
46MUST3.7.1"represent entity-bodies in canonical media-type form (except ""text"" types) prior to content-coding them"
47MUST3.7.1"label data in charsets other than ISO-8859-1"" with an appropriate charset value."
48MUST3.7.2include a boundary parameter as part of the media type value for multipart media types
49MUST3.7.2only use CRLF in multipart messages to represent line breaks between body-parts.
50MUST3.7.2have the epilogue of multipart messages empty
51MUST NOT3.7.2transmit the epligoue of multipart messages (even if given one)
52SHOULD3.7.2follow the same behaviour as a MIME agent when receiving a multipart message-body.
53MUST3.7.2"treat unrecognized multipart subtypes as ""multipart/mixed"""
54SHOULD3.8use short to the point product-tokens
55MUST NOT3.8use product tokens for advertising or non-essential info
56MAY3.8use any token character in a product-version
57SHOULD3.8only use product-version tokens for a specific version
58SHOULD3.8only change the product-version portion of a product value when changing version numbers
59MUST NOT3.9generate more than 3 digits after the decimal point in quality values
60SHOULD3.9limit user configuration to 3 digits on quality values
61MUST3.10use rfc 1766 language tags in the accept-language and content-language fields
62MAY3.11"provide the same ""strong"" entity tag for two resources only if they are equivalent by octet equality"
63MAY3.11"provide the same ""weak"" entity tag for two resources only if they are equivalent and can be substituted with no significant semantic changes"
64MUST3.11when giving entity tags provide unique entity tags for all versions of entities associated wth a particular resource
65MAY3.11provide the same entity tag value for different resource URIs - note that this does no imply entity equivalnce across resources
66MAY3.12"ignore unrecognized ranges specified with units other than ""bytes"""
67SHOULD4.1ignore empty lines where the Request-Line is expected
68MUST NOT4.1preface or follow a request with an extra CRLF
69MAY4.2precede header field values with LWS - although a single SP is preferred
70MUST4.2precede extra lines in header fields with a single SP or HT
71MAY4.2replace LWS in field values with a single SP
72MAY4.2remove leading or trailing LWS on header fields
73recommendation4.2"send general-headers, then request/response headers, and then entity-headers"
74MUST4.2"when generating multiple message header fields with the same field-name, be possible for the client or downstream to combine by appending "", field-value"" in the order received to generate one long header-field"
75MUST NOT4.2alter the order on multiple message headers with the same field-name
76MUST4.3use Transfer-Encoding to indicate any transfer encodings used when transmitting messages.
77MAY4.3add or remove Transfer-Encoding along the request chain (ie receive a message as a plain entity-body and transfer-encode via gzip for transmission downstream
78MUST NOT4.3include a message-body in a request if the request-method does not allow it
79SHOULD4.3read and forward message-bodies on any request
80SHOULD4.3ignore message-bodies when semantics for the requests method do not define a message-body
81MUST NOT4.3include a message-body in a response to a HEAD request
82MUST NOT4.3 "include a message body in 1xx, 204 and 304 reponses"
83MUST4.3"include a message body in all other responses, although it MAY be zero length"
84MUST4.4"assume message termination by the first empty line after the header fields in responses that ""MUST NOT"" have message bodies (ie 1xx, 204, 304 and HEAD requests)"
85MUST NOT4.4send a Content-Length header if the entity-length and the transfer-length are not equal
86MUST4.4ignore the Content-Length header if a Transfer-Encoding header is received
87MUST NOT4.4send media type multipart/byteranges unless we know the recipient can parse it.
88MUST4.4"delimit the reponse message by one of 1) the first empty line if no message body defined(see 4.3), 3) Content-Length header or 5) close the connection when sending a response of type multipart/byteranges to a 1.0 Proxy which forwarded the request from a client that does understand"
89MUST4.4include a Content-Length header in requests containing a message body unless the server is known to be 1.1 compliant.
90SHOULD4.4return 400 bad request if it cannot determine the length of a request message or 411 if we wish to enforce receiving a valid content-length
91MUST NOT4.4include both Content-Length and a non-identity transfer coding.
92MUST4.4ignore the Content-Length header if a non-identity Transfer-Encoding is received. (perhaps covering for TE instead of Transfer-Encoding??)
93MUST4.4IF we are acting like a user agent - ie 'client' - notify the user when an invalid length is received and detected - ie Content-Length does not match the number of octects in the message-body.
94MUST4.4"when sending a reponse where a message body is allowed and we include Content-Length, it's value must match the number of OCTECTS in the message-body"
95MUST4.5treat unrecognized header fields as enitity header fields
96SHOULD5.1.1return 405 if a request method is recognized but not allowed
97SHOULD5.1.1return 501 if a request method is not implemented
98MUST5.1.1support GET and HEAD for squid generated pages
99MUST5.1.1implementh other methods beyond GET and HEAD in accordance with rfc 2616
100MUST5.1.1"recognize all squid server names, including any aliases, local variations, and the numeric IP address"
101MUST5.1.1accept absolute URI's for all requests.
102MAY5.1.1forward requests to other proxies or to the origin server.
103MUST5.1.2decode URI's with % HEX HEX format before interpreting the request.
104SHOULD5.1.2return appropriate status codes to invalid Request-URIs
105MUST NOT5.1.2"in transparent mode; rewrite the abs_path in thr Request-URI (ither than replacing a null abs_path with ""/"")"
106MUST5.2for absolute Request-URI's ignore any host header field in the request
107MUST5.2for non-absolute Request-URI's with a host header use the host head field value
108MUST5.2for non-absolute Request-URI's with no host header return 400
109MUST NOT5.2generate responses with CR or LF except at the end of the status line
110MUST6.1understand the class of status codes (the 1st digit) and treat unrecognized responses as x00.
111MUST NOT6.1cache responses with unrecognized status codes
112MAY7transmit an entity if not otherwise restricted by the request method or response code
113MUST7.1in transparent mode: forward unrecognized header fields
114SHOULD7.2.1include a Content-Type header for generated HTTP/1.1 messages w/entity bodies
115SHOULD7.2.1treat unknown media-types as application/octet-stream
116SHOULD8.1.1implement HTTP/1.1 persistent connections
117SHOULD8.1.2assume http/1.1 servers will maintain persistent connections even after error responses from the server
118MUST NOT8.1.2send more requests on a connection afer a close is signaled
119MAY8.1.2.1Assume a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header with token close was received in the request
120SHOULD8.1.2.1Send a Connection header with token close if we want to close the client side connection immediately after sending the response
121MAY8.1.2.1expect a connection to remain open - but decide based on the server response (does it have a connection header with token close)?
122SHOULD8.1.2.1send a Connection header with token close if we want to only send one request and then close the server side connection
123SHOULD NOT8.1.2.1assume a persistent connection is maintained for pre-HTTP/1.1 versions unless it is explicitly signlaed.
124MUST8.1.2.1always create messages with self-defined message lengths
125MAY8.1.2.2pipeline requests to upstream servers
126MUST8.1.2.2send reponses to pipelined requests in the order that the requests were received
127SHOULD8.1.2.2"if we assume persistent connections to servers, and pipeline immediately after connection, be prepared to retry the connection if the first pipelined attempt fails"
128MUST NOT8.1.2.2"when retrying a failed (if we assume persistent connections to servers, and pipeline immediately after connection, be prepared to retry the connection if the first pipelined attempt fails) pipeline before we know the connection is persistent"
129MUST8.1.2.2be prepared to resend requests if a server closes the connection before sending all the pipelined requests
130SHOULD NOT8.1.2.2pipeline non idempotent methods or non-idempotent sequences of methods.
131SHOULD8.1.2.2wait to send non-idempotent requests after receiving the reponse status for the previous request
132recommendation8.1.3implement the Connection header field properly
133MUST8.1.3signal persistent connections separately with clients and upstream servers
134MUST NOT8.1.3establish a HTTP/1.1 persistent connection with a HTTP/1.0 client
135SHOULD8.1.4issue a graceful close on the transport connection when timing out persistent connections
136SHOULD8.1.4watch persistent connections for close signals and respond to it as appropriate
137MAY8.1.4close any connection at any time.
138MUST8.1.4be able to recover from asynchronous close events.
139SHOULD8.1.4after an asynchronous close event reopen the transport connection and retransmit the aborted sequence automatically as long as the request is idempotent
140MUST NOT8.1.4after an asynchronous close event reopen the transport connection and retransmit the aborted sequence automatically if the request is non-idempotent
141SHOULD8.1.4always respond to at least one request per connection if possible
142SHOULD NOT8.1.4"close a connection in the middle of transmitting a response, unless network or client failure is suspected"
143SHOULD8.1.4for the client program - limit the number of silmutaneous connections maintained to a given server.
144SHOULD NOT8.1.4for the client program - maintain more than 2 connections with any given server or proxy
145SHOULD8.1.4"for the proxy - use up to 2*N with another server or proxy, when N is the number of simultaneous connected active users"
146SHOULD8.2.1maintain persistent connections and use TCP flow control to resolve link congestion rather than terminating connections abruptly
147SHOULD8.2.2when sending message-bodies monitor the net connection for error's.
148SHOULD8.2.2when sending message-bodies and a net error is detected immediately cease transmitting the body.
149MAY8.2.2"when sending message-bodies using ""chunked"" encoding and a net error is detected immediately cease transmitting the body & mark the termination with a zero length chunk and an empty trailer"
150MUST8.2.2when sending message-bodies preceded by a content-length header and a net error is detected immediately cease transmitting the body and close the connection
151MUST8.2.3"for the client program - if waiting for 100 before sending the request body send an Expect request-header with the ""100-continue"" expectation"
152MUST NOT8.2.3"for the client program - send an Expect request-header with the ""100-continue"" expectation if we do not intend to send a request body"
153SHOULD NOT8.2.3"for the client program - if waiting for 100 before sending the request body, do not wait for an indefinate period before sending the request body"
154MUST8.2.3"for the squid 'server' - when we receive a request with an Expect request-header with the 100-continue expectation, respond with status 100 and continue reading from the input stream, or response with a final status code"
155MUST NOT8.2.3"for the squid 'server' - when we receive a request with an Expect request-header with the 100-continue expectation, wait for the request body before sending the 100 response."
156MAY8.2.3"for the squid 'server' - when we receive a request with an Expect request-header with the 100-continue expectation and send a final status code, close the transport connection"
157MAY8.2.3"for the squid 'server' - when we receive a request with an Expect request-header with the 100-continue expectation and send a final status code, finish reading the request (and discard it)"
158MUST NOT8.2.3"for the squid 'server' - when we receive a request with an Expect request-header with the 100-continue expectation and send a final status code, finish reading the request and perform the requested method"
159SHOULD NOT8.2.3for the squid 'server' - send a 100 continue status if the request header does not include an Expect request header with the 100-continue expectation
160MUST NOT8.2.3for the squid 'server' - send a 100 continue status if the request comer from a pre HTTP/1.1 client.
161MAY8.2.3for the squid 'server' - send a 100 continue status in response to a (only) HTTP/1.1 PUT or POST request that does not include an expect header with the 100-continue expectation
162MAY8.2.3for the squid 'server' - omit a 100 continure status if some or all of the request body has already been received
163MUST8.2.3"for the squid 'server' - send a final status code after one or more 100 codes, unless the transport connection is terminated prematurely"
164SHOULD NOT8.2.3for the squid 'server' - close the transport connection we are receiving a request body on until the entire request is read or the client closes the connection even if we have already sent a final status code
165MUST8.2.3"when receiving a request with an Expect header with the 100-continue expectation and the next-hop server is HTTP/1.1 or higher, or version unknown, forward the request including the Expect header field"
166MUST NOT8.2.3"when receiving a request with an Expect header with the 100-continue expectation and the next-hop server is HTTP/1.0 or lower, forward the request"
167MUST8.2.3when receiving a request with an Expect header with the 100-continue expectation and the next-hop server is HTTP/1.0 or lower respond with 417 status
168SHOULD8.2.3cache the http version of recently access next hop servers
169MUST NOT8.2.3forward a 100 reponse if the request was received from a HTTP/1.0 or earlier client and did not include an expect header field with the 100 continue expectation
170SHOULD8.2.4"retry requests sent when the connection closes before receiving any status from the server AND there was a request body AND the request did not have an Expect field with expectation 100-continue AND we are not ""directly connected to an HTTP/1.1 origin server"""
171MAY8.2.4"Time ""retry requests sent when the connection closes before receiving any status from the server AND there was a request body AND the request did not have an Expect field with expectation 100-continue AND we are not ""directly connected to an HTTP/1.1 origin server"" "" witha binary exponential backoff algorithm"
172SHOULD NOT8.2.4continue retring requests as per rfc 8.2.4 when an error status is received
173SHOULD8.2.4close the connection if the request has not completed sending when we are (retrying requests as per rfc 8.2.4 when an error status is received)
174MUST9send the Host request-header field with ALL HTTP/1.1 requests
175SHOULD NOT9.1.1use GET and HEAD methods for anything other than retrieval (no side effects by squid)
176SHOULD NOT9.1.2have side effects caused when receiving requests to squid with OPTIONS or TRACE as the method
177MUST NOT9.2cache the results from an OPTIONS request
178MUST9.2for the client program - include a content type field when sending an OPTIONS request with an entity body
179MAY9.2for the squid 'server' - discard the request body from OPTIONS requests
180SHOULD9.2200 responses to the method OPTIONS should include any header fields that indicate optional features implemented by the server and applicable to that resource (eg Allow)
181SHOULD9.2200 responses to the method OPTIONS with a message body should include information about the communications options
182MAY9.2use content-negotiation to select the format for information about the message body in 200 responses to the method OPTIONS
183MUST9.2include a Content-length header value of 0 or a reponse body in 200 responses to the method OPTIONS
184MAY9.2for the client program - use the Max-Forwards request-header to target a specific proxy in the request chain.
185MUST9.2check for a Max-Forwards field when squid recieves an OPTIONS request on an absoluteURI for which request forwarding is permitted
186MUST NOT9.2forward a request with a Max-Forwards field when squid recieves an OPTIONS request on an absoluteURI for which request forwarding is permitted and the value of Max-Forwards is 0.
187SHOULD9.2response with Squids communications options to an OPTIONS request with a Max-Forwards field on an absoluteURI for which request forwarding is permitted and the value of Max-Forwards is 0.
188MUST9.2decrement the Max-Forwards field-value when forwarding an OPTIONS request with a Max-Forwards field on an absoluteURI for which request forwarding is permitted and the value of Max-Forwards is a non zero integer.
189MUST NOT9.2add a Max-Forwards header to an OPTIONS request if non is present when squid recieves it
190MUST NOT9.3cache a GET response if it does not meet the HTTP caching requirements from rfc 2616 section 13
191MUST NOT9.4for the squid 'server' - generate a message-body in HEAD responses
192SHOULD9.4for the squid 'server' - generate identical http headers for a HEAD request to the equivalent GET request.
193MAY9.4update previously cached entities with the headers from a HEAD requests' response
194MUST9.4"mark as stale cached entities where a HEAD requests' response indicate a change in the entity (as indicated by a change in Content-Length, Content-MD5, Etag or Last-Modified)"
195MUST9.5follow the section 8.2 message transmission requirements for POST requests
196MUST NOT9.5cache POST responses unless they include appropriate cache-control or Expires headers
197SHOULD9.6for the squid 'server' - handling PUT requests - I skipped these as the cachmgr interface has not file storage capability
198SHOULD9.6treat any cached entities that match the Request URI of a PUT request as stale
199MUST9.6follow the section 8.2 message transmission requirements for PUT requests
200MUST NOT9.6cache responses to PUT Method requests
201SHOULD9.7for the squid 'server' - handling DELETE requests - I skipped these as the cachmgr interface has not file storage capability
202SHOULD9.7treat any cached entities that match the Request URI of a DELETE request as stale
203MUST NOT9.7cache responses to DELETE Method requests
204MUST NOT9.8for the squid client - create TRACE requests with an entity
205SHOULD9.8reflect back to the client the TRACE message received (when the Max-forwards value is 0) as the entity-body of a 200 response. The entity body is to have content type message/http
206MUST NOT9.8cache responses to TRACE Method requests
207MUST NOT10.1for the squid 'server' - send 1xx response codes to < HTTP/1.1 clients
208MUST10.1"for the client - be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 status message"
209MUST10.1"forward 1xx responses unless the connection squid-client has been closed, or squid requested the generation of the 1xx response. (I.e, squid added expect: 100-continue then squid does not need to forward the 100 response"
210SHOULD10.1.1for the client when getting a 100-continue reponses should continue with the request or ignore if the request has been completed.
211MUST10.1.1for the squid 'server' - send a final reponse after handling the request
212SHOULD10.1.2only upgrade protocols when it is advantageous to do so.
213MUST10.2.2for the squid 'server' - handling PUT requests - I skipped these as the cachmgr interface has not file storage capability
214MUST10.2.5teminate 204 responses by the first empty line after the header field
215MUST NOT10.2.6include entities in 205 responses
216MUST NOT10.2.7combine 206 responses with older content for the same entity unless the Etag or Last-Modified headers match exacly
217MUST NOT10.2.7cache 206 reponses unless we support Range and Content-Range headers
218MUST10.2.7include the following headers in 206 reponses downstream - Content-Range or a multipart/byteranges content-type with content-range for each part.; Date ; Etag and/or Content-Location; Expires/cache0control and/or vary if the field value might differ from that send in any previous request for the same variant
219MUST10.2.7206 responses to requests with if-range & strong validator - should not have other entity headers; if-range and weak validator - MUST NOT have other entity headers; other wise include all entity headers a 200 response would have given to the same request
220SHOULD10.3.2cache 301 responses unless otherwise indicated
221MUST NOT10.3.2cache 301 responses to requests other than GET or HEAD
222MUST NOT10.3.3cache 302 responses unless indicated by a Cache-Control or Expires header
223MUST NOT10.3.3cache 302 responses to requests other than GET or HEAD
224MUST NOT10.3.4cache 303 responses
225MUST10.3.5"for the squid 'server' - in 304 responses include the Date (unless rfc 2616 ection 14.18.1 requires its omission); Etag and/or Content-Location (if a 200 response to same would have those fields); Expires, Cache-Control and/or Vary if the field value might differ from that sent in any previous request"
226MUST10.3.5"when a 304 response indicates a not-currently-cached entity, disregard the response and repeat the request with no conditions"
227MUST10.3.5"when a 304 response is received for a currently cached entity, update the entry with new field values given in the response"
228MUST10.3.6"when a 305 response is received, repeat that _single_ request via the proxy in 'Location'"
229MUST NOT10.3.6generate 305 responses except from the squid 'server'
230MUST NOT10.3.7use the 306 status code
231SHOULD NOT10.4.1retry requests where 400 was returned unless the client retries
232SHOULD NOT10.4.4retry requests where 403 was returned
233MUST10.4.6include an Allow header listing valid methods for requests where squid creates a 405 method to the client
234MUST10.4.8return a Proxy-Authenticate header containing a challenge applicable to squid for the requested resource.
235MAY10.4.9retry 408 requests
236SHOULD NOT10.4.10retry 409 responses automatically
237SHOULD10.4.11cache 410 responses
238MAY10.4.12automatically retry a request with a Content-Length header in response to a 411 error
239MAY10.4.12return a 411 error to the client if we want to be able to filter easily on put and post requests and the client did not use a Content-Length header
240MAY10.4.14return a 413 error when the request entity is too large.
241SHOULD10.4.14"When returning a 413 error when the request entity is too large and it is a time based (or temporary) restriction, include a Retry-After header indicating when it should be ok"
242SHOULD10.4.18return 417 when we have unambigous evidence that the expectation given in a request can not be met by the next hop server
243SHOULD10.5include an entity body when we create 5xx error reponses explaining the issue (other than to HEAD requests)
244SHOULD10.5.2return a 501 if we don't implement a given method and can't just proxy it an hope
245SHOULD10.5.3return a 502 if we get an invalid upstream response
246SHOULD10.5.4"return a 503 if we are overloaded, or unable to serve requests due to maintenance."
247MAY10.5.4"return a Retry-After when returning a 503 if we are overloaded, or unable to serve requests due to maintenance. (the header would indicate when the maintenance should finish"
248SHOULD10.5.5"return a 504 on an upstream timeout, or timeout on an auxilary server - ie DNS/authentication helper"
249MUST10.5.6"return a 505 if we don't support, (or have #defed it out) the HTTP major version in the request message"
250OPTIONAL11implement basic and or digest authentication
251MAY12use content-negotiation on any entity body request/response - ie in selecting what language the error should be in
252MAY12.1"for the squid client - include request header fields (Accept, Accept-Language, Accept-Encoding etc) in requests"
253MAY12.3develop transparent negotiation capabilities within HTTP/1.1
254recommendation13"Note: The server, cache, or client implementor might be faced with design decisions not explicitly discussed in this specification. If a decision might affect semantic transparency, the implementor ought to err on the side of maintaining transparency unless a careful and complete analysis shows significant benefits in breaking transparency."
255MUST13.1.1"respond to a request with the most up-to-date response held by squid which is appropriate to the request (see 13.2.5,13.2.6,13.12) and meets one of : 1) it has been revalidated with the origin, 2) it is ""fresh enough (see 13.12) & 14.9 or 3) it is an appropriate 304/305/ 4xx/5xx response"
256MAY13.1.1"If a stored response is not ""fresh enough"" by the most restrictive freshness requirement of both the client and the origin server, in carefully considered circumstances the cache MAY still return the response with the appropriate Warning header (see section 13.1.5 and 14.46), unless such a response is prohibited (e.g., by a ""no-store"" cache-directive, or by a ""no-cache"" cache-request-directive; see section 14.9)."
257SHOULD13.1.1forward received responses even if the response itself is stale without adding a new Warning header
258SHOULD NOT13.1.1attempt to revalidate responses that become stale in transit to squid
259SHOULD13.1.1responsd as per the 13.1.1 respond rules even if the origin server cannot be contacted.
260MUST13.1.1"return an error or warning to the client if the origin server can't be contacted, and no response can be served under the 13.1.1 rules"
261MUST13.1.2"attach a warning noting when returning a response that is neither first-hand nor ""fresh enough"" using the Warning header"
262MUST13.1.2delete 1xx warnings from cached responses after succesful revalidation
263MAY13.1.2generate 1xx warnings when validating a caced entry
264MUST NOT13.1.2delete 2xx warning from cached responses after succesful revalidation
265MAY13.1.2choose the warning text description language (perhaps based on Accept headers)
266MAY13.1.2"allow/create responses with multiple warnings, including multiple warnings with the same code"
267recommendation13.1.3use the most restrictive interpretation of caching issue /spec conflicts
268MAY13.1.5have squid configurable to return stale responses even when not requested by clients
269MUST13.1.5mark stale responses with a Warning header
270SHOULD NOT13.1.5"return a stale response if the client explicitly requests a first-hand or fresh one, unless technical or policy reasons require returning a stale response"
271SHOULD13.2.3be running on a host that uses NTP or equivalent for clock synchronization
272MUST13.2.3"calculate corrected_received_age as max(now-date_value, age_value)"
273MUST13.2.3"interprest Age header values (age_value) relative to the time the request was initiated, not the response time."
274MUST13.2.3calculate corrected_initial_age as corrected_received_age +(now - request_time) ; request_time = time the request was sent upstream
275MUST13.2.3when sending responses from cached entries include a single Age header with a value equal to current_age (as per 13.2.3 algorithm)
276MAY13.2.4"compute freshness lifetime using a heuristic IFF the response has no caching restrictions AND no Expires, Cache-Control: Max-age, Cache-Control: s-maxage exist in the response"
277MUST13.2.4attach a Warning 113 to any response when the age_value is more than 24 hours if there is no 113 warning already
278SHOULD13.2.4use heuristics that use a fraction of the last-modified time (if it exists) - suggested setting of 10% since last-modified
279MUST13.2.5"when two responses exist for a given representation with different validators, use the one with the more recent Date header."
280SHOULD13.2.6"When a revalidation occurs and the responses date header is older than the existing entry, repeat the request unconditionally, with the header Cache-Control: max-age=0 or Cache-Control: no-cache"
281MUST NOT13.3.3use a weak validator in anything other than simple (non-subrange) GET requests
282MUST13.3.3"consider two validators strongly equal IFF both validators are identical, and both are NOT weak"
283MUST13.3.3"consider two validators weakly equal IFF both validators are identical, and one or both are NOT strong"
284MUST13.3.3"consider Last-Modified to be a weak validator unless we are comparing it with a cached last-modified date, and the cache entry includes a Date value, and the last-modified is at least 60 seconds before the data value"
285MUST13.3.3when receiving conditional requests the use strong comparison (no weak compares allowed)
286MUST NOT13.3.4return 304 to a conditional request that includes both a last-modified (eg in a IMS or IUS header) and one or more entity tags (eg If-match / IF-None-Match/If?-Range) unless the 304 is consistent with all the conditionals present in the request
287MUST NOT13.3.4return a locally cached response to a conditional request that includes both Last-Modified and one or more entity tags as validators unless the cached response is consistent with all present conditionals in the request
288MUST NOT13.3.5use other headers than entity tags and Last-Modified for validation
289MAY13.4always cache a successful response (unless constrained by 14.9)
290MAY13.4return cached responses without validation while fresh (unless constrained by 14.9)
291MAY13.4return cached responses after succesful validation (unless constrained by 14.9)
292MAY13.4"cache responses with no validator or expiration time, but shouldn't do so in normal conditions"
293MAY13.4"cache and use as replies, responses with status codes 200, 203, 206, 300, 301 or 410 (subject to expiration & cache-control mechanisms)"
294MUST NOT13.4"return responses to status codes other than (200, 203, 206, 300, 301 or 410) in a reply to subesquent requests unless there are cache-control directives that explicitly allow it (eg Expires/ a max-age , s-maxage, must-revalidate, proxy-revalidate, puvlic or private cache-control header"
295MUST13.5.1store end to end headers (headers other than Connection; Keep-Alive ; Proxy-Authenticate ; Proxy-Authorization ; TE ; Trailers ; Transfer-Encoding ; Upgrade) with the cached response
296MUST13.5.1transmit cached end to end headers in any response fromed from that cache entry
297MUST13.5.1list newly defined hop to hop headers under the connection header
298SHOULD NOT13.5.2modify end to end headers unless the definition of that header specifically allows or requires its modification
299MUST NOT13.5.2as a transparent proxy; modify (Content-Location; Content-MD5;- Etag; Last-Modified; Expires) headers in a request or response
300MAY13.5.2"as a transparent proxy; add an Expires header if not already present in a reponse, and MUST give it the same value as the Date header of that response"
301MUST NOT13.5.2as a transparent proxy; add (Content-Location; Content-MD5;- Etag; Last-Modified) headers in a request or response
302MAY13.5.2"as a non-transparent proxy; modify or add (Content-Location; Content-MD5;- Etag; Last-Modified; Expires) headers in a request or response that does not include ""no-transform"""
303MUST13.5.2"add a warning 214 (if not already present) if we choose to as a non-transparent proxy; modify or add (Content-Location; Content-MD5;- Etag; Last-Modified; Expires) headers in a request or response that does not include ""no-transform"""
304MUST13.5.2as a transaprent proxy; preserve the entity-length of the entity body in a response/request
305MAY13.5.2as a transaprent proxy; change the preserve the transfer-length in a response/request
306MAY13.5.3combine 206 responses with cached content for the same entity as long as the Etag or Last-Modified headers match exactly
307MUST13.5.3update any end-end headers in cache entries with those from a 304 or 206 response or remove the cache entry
308MUST13.5.3"when combining 206 responses with cached content, remove Warning 1xx headers, retain warning 2xx headers, and use the 206 responses end to end headers in preference to the cached headers"
309MAY13.5.4"combine byte ranges if both the incoming response and the cache entry have validotrs, and the validators match using the strong comparison"
310MUST13.5.4"if a subrange response is received, and with either the incoming response or the cache entry has no validator, or the validators do no compare strongly, only use the most recent (check Date header else the incoming response) partial response and discard the previous partial information"
311MUST NOT13.5.6"use a cache entry to construct a response to a request when the response had a Vary header, unless all the listed (by the vary field) request headers match the corresponding cached request headers (match by transforming by insertion of LWS as allowed by the BNF's and or combining message-header fields with the same name as per 4.2"
312MUST NOT13.5.6use a cache entry to construct a response to a request when the response had a Vary header of * without validation by the origin server
313SHOULD13.5.6"if an entity tag is assigned to a cached representation, the forwarded request should be conditional and include the entity tags in an If-None-Match header field from _all_ the cache entries for the resource"
314SHOULD NOT13.5.6include the entity-tag for a cache entry that only contains partial content in the If-None-Match header unless the request could be satisfied from the cache
315SHOULD13.5.6"delete cache entries when a successful response with a matching Content-Location field, a differing entity-tag and a more recent Date"
316SHOULD NOT13.5.6"use cache entries when a successful response with a matching Content-Location field, a differing entity-tag and a more recent Date to satisfy requests"
317MAY13.8store incomplete responses
318MUST13.8treat incomplete responses as partial responses
319MUST NOT13.8return a partial response to a client without marking it as such (using 206 status code)
320MUST NOT13.8return a partial response to a client with status 200
321MAY 13.8"forward 5xx responses received while revalidating entries to the client, or act as if the server failed to respond"
322MAY13.8"when a server fails to respond, return a cached response unless the cached entry inludes the must-revalidate cache-control directive"
323MUST NOT13.9treat GET and HEAD requests with ? In the URI path as fresh UNLESS explicit exipration times are provided in the repsonse
324SHOULD NOT13.9cache GET and HEAD responses from HTTP/1.0 servers with ? In the URI path
325MUST13.10invalidate entities referred to by the Content-Location header;Location header or the Request-URI in PUT/DELETE and POST requests. This is only done for the same host hwn using the Content-Locaiton and Location headers
326SHOULD13.10invalidate entities referred to by the Request-URI in non understood methods if we pass them upstream
327MUST13.11pass upstream all methods that may cause alterations to the origin servers resources. (This means all Methods other than GET and HEAD)
328MUST NOT13.11respond to a client on all methods that may cause alterations to the origin servers resources. (This means all Methods other than GET and HEAD) before the reponse from the server arrives.
329MAY13.11respond to a client with a 100 on all methods that may cause alterations to the origin servers resources. (This means all Methods other than GET and HEAD) before the reponse from the server arrives.
330SHOULD13.12"when a new response to an existing cached resource arrives, use the new response to reply to the current request"
331MAY13.12"when a new response to an existing cached resource arrives, update the cache with the new response"
332MAY13.12"when a new response to an existing cached resource arrives, use it to respond to future requests as appropriate"
333MAY14.1include parameters for media types that support them
334MAY14.1include accept-params for media types. (q=0 to q=1) (see 3.9)
335SHOULD14.1for the squid 'server' send 406 if we cannot get an acceptable media type for the client request
336MAY14.2have q values for charsets
337SHOULD14.2for the squid 'server' send 406 if we cannot get an acceptable charset for the client request
338MAY14.3have q values for content-coding
339SHOULD14.3for the squid 'server' send 406 if we cannot get an acceptable content-coding for the client request. Note this is not transfer-coding so we do cannot do this on the fly for the cache
340MAY14.3assume the client will accept any content coding when to Accept-Encoding header is presented
341SHOULD14.3for the squid 'server' send identity content-coding when no Accept-Encoding header is presented
342MAY14.4have q values for preferred language
343SHOULD14.4assume all languages are ok when there is no header
344MAY14.5for the squid 'server' send Accept-ranges: none to tell clients not to attempt range requests
345MUST14.6"when an age header we receive is larger than our largest integer, or if an Age calculation overflows, transmit age of 2147483648 (231). "
346SHOULD14.6use integers of at least 31 bits
347MUST14.7present an Allow header in 405 responses
348MUST NOT14.7modify the allow header
349SHOULD14.8have a set of credentials valid for an entire realm (including all sub-resources) (ie for web-accel operation)
350MUST NOT14.8return responses with Authorization headers to other requests unless a) cache-control: s-maxage is present or b) cache-control: must-revalidate is presented or c) cache-control: public is present
351MUST14.8always revalidate responses with cache-control: s-maxage=0
352MUST14.9follow the cache-control header directives at all times
353MUST14.9pass cache-control directives through to the next link in the message path (ie don't eat them)
354MAY14.9.1cache responses with cache-control: public even of the header/method might not normally be cacheable
355MUST NOT14.9.1cache responses with cache-control: private
356MUST NOT14.9.1use responses with cache-control: no-cache to satisfy other requests without successful revalidation
357MAY14.9.1use responses with cache-control: no-cache to satisfy other requests without successful revalidation if the no-cache directive includes field-names
358MUST NOT14.9.1send the headers listed in responses with cache-control: no-cache to satisfy other requests without successful revalidation if the no-cache directive includes field-names
359MAY14.9.2use no-store on requests or responses to prevent data storage
360MUST NOT14.9.2store any part of a request or it's response if the cache-control: no-store directive was in the request
361MUST NOT14.9.2store any part of a response or the request that elicited it if the cache-control: no-store directive was in the response
362SHOULD14.9.3consider responses with an Expires value that is <= the response date and no cache-control header field to be non-cacheable
363MUST14.9.3mark stale responses with Warning 110
364MAY14.9.3have squid configurable to return stale responses even when not requested by clients but responses served MUST NOT conlict with other MUST or MUST NOT requirements
365MUST NOT14.9.4use a cached copy to respond to a request with cache-control: no-cache or Pragma: no-cache
366SHOULD14.9.4response with a cached copy (if possible) or a 504 to a request with cache-control: only if cached. Note we can use a cache farm to get the cached copy
367MUST NOT14.9.4use stale responses marked with cache-control: must-revalidate after it becomes stale without first revalidating it with the origin
368MUST14.9.4obey the must-revalidate directive at all times
369MUST14.9.4return 504 if a must-revalidate directive would need access to an unavailable origin server
370MUST NOT14.9.5change any headers (or part of the request specified by those headers) from section 13.5.2 when a message with cache-control: no-transform is received
371MUST14.9.6ignore unrecognized cache-control headers
372MUST14.10parse the Connection header before a message is forwarded
373MUST14.10remove headers from messages that match headers specified in the connection header
374MUST NOT14.10list end to end headers in the connection header
375MUST14.10for applications that do not support persistent connection (ie squid 'server' and client) include Connection: close in every message
376MUST14.10"on pre-http/1.1 messages with a connection header, for each connection-token, remove AND ignore and header fields with the same name as the token"
377MAY14.11as a NON-TRANSPARENT proxy modify content-coding to be more suitable to a client request
378MUST14.11"if the content encoding of an entity is not ""identity"""
379MUST14.11list in applied order the content codings applied to an entity
380MAY14.12list multiple languages in a Content-Language header if the reponse is intended for multiple audiences (perhaps a multi-lingual error page?)
381SHOULD14.13use and send the Content-Length header unless prohibited by section 4.4
382MUST NOT14.15generate Content-MD5 headers
383MAY14.15check Content-MD5 headers
384MUST14.15remove transfer-encodings before checking the MD5
385MUST NOT14.15convert line breaks to CRLF before checking the MD5
386SHOULD14.16indicate the total length of the full entity body in Content-Range headers
387MUST14.16only specify one range in byte-range-resp-spec
388MUST14.16use absolute byte positions for byte-range-resp-spec values
389MUST14.16ignore invalid byte-range-resp-spec and any content transferred with it
390MUST NOT14.16have response code 206 with a byte-range-resp-spec of *
391MUST14.18"assign a Date header if we receive a message without one,"
392SHOULD14.18assign the best available approximation of the date and time of message generation when we assign Date headers
393MAY14.19use Entitiy tags for comparison with other entities from the same resource
394MUST14.21treat invalid Expires headers (NON RFC 1123 format) as being in the past
395MAY14.22log the From header
396SHOULD NOT14.22use the From header for access-control
397MUST14.23for clients: include a Host header in all http/1.1 requests
398MUST14.23for clients: include an empty Host header in all http/1.1 requests when no host name is available
399MUST14.23ensure that all requests forwarded include an appropriate Host header
400MUST14.23respond with 400 to http/1.1 requests missing a Host header
401MUST14.24use the strong comparison when comparing entity tags for If-Match
402SHOULD14.25return a 304 to IMS requests that have not been modified (using cached data if possible)
403MUST14.31check and decrement (if greater than 0) the Max-Forwards header if present in TRACE and OPTIONS requests
404MUST14.31respond as the final recipient if the Max-Forwards header is 0 on a TRACE or OPTIONS request
405MAY14.31ignore the Max-Forwards header for all other methods covered by rfc 2616
406SHOULD14.32forward requests with Pragme: no-cache upstream even if a cached copy exists
407MUST14.32pass Pragma directives up/downstream in all cases
408SHOULD14.32ignore pragma directives not relevant or understood by us
409SHOULD14.32treat pragme: no-cache ascache-control: no-cache
410MUST14.33include Proxy-Authenticate when sending a 407 response
411SHOULD NOT14.33pass Proxy-Authenticate downstrem
412MAY14.34relay credentials from a client upstream to a parent cache (if that is the mechanism by which the two caches cooperatively authenticate a given request)
413MAY14.35.1specify a single byte range or a set of ranges within a single entity with a single byte range operation
414MUST14.35.1have the last-byte-pos value (if present) great than or equal to the first-byte-pos in the byte-range-spec
415MUST14.35.1ignore a header field with an invalid byte-range-spec
416SHOULD14.35.1return 416 if a byte-range-set is unsatisfiable
417SHOULD14.35.1return 206 when returning ranges
418MAY14.35.2for the client - request one or more subranges on conditional or un-conditional GET requests
419MAY14.35.2ignore the range header.
420SHOULD14.35.2only return the requested range to a client even if we get given the entire entity in response to a request containing a range request
421SHOULD14.35.2store the entire response (if we would normally cache that object) if we get given the entire entity in response to a request containing a range request
422MUST NOT14.36for the client - send a referer field if the request-URI was not obtained from a source with it's own URI - ie the keyboard
423MAY14.37use Retry-After to indicate how long a client should wait before requesting the new location
424MUST NOT14.38modify the Server header on forwarded responses
425SHOULD14.38include a Via header on forwarded resposnes
426MUST14.39include the TE connection token whenever we use TE on a connection
427SHOULD NOT14.40include header fields in the trailer with having sent a Trailer header
428MUST NOT14.40send Transfer-Encoding; Content-Length or Trailer as Trailer field values
429MUST14.41"list in the order applied the transfer-encodings applied to a response (ie rsync, gzip"
430MUST14.42use the upgrade header in a response with status code 101
431MUST14.42include the Upgrade connection-token whenever we use the Upgrade header
432SHOULD14.43for the client - include a user-Agent field in requests
433SHOULD14.44include a Vary header on any cacheable response we generate that used server negotiation
434MAY14.44for the 'server' include a vary header with a non-cacheable resposne the used server negotiation
435MAY14.44assume the same response will be given by a server for future requests with the same request field values as those listed by the vary header in the response whilst the response is still fresh
436MUST NOT14.44generate a * value for a vary field
437MUST14.45fill in the Via header
438MAY14.45replace the host in the via header with a pseudonym for security/privacy
439MUST14.45append our details to the Via header
440MAY14.45remove comments from the via header before forwarding
441MAY14.45put comments in the via header before forwarding
442SHOULD NOT14.45when used as a gateway/ http firewall forward names/hosts/ports of hosts within the firewall
443SHOULD14.45require explicit enablement of forwarding names/hosts/ports of hosts within the firewall
444SHOULD14.45replace the received-by host with a pseudonym when used as a gateway/ http firewall forward names/hosts/ports of hosts within the firewall
445MAY14.45for organisations with privacy concerns: collapse multiple protocol-value entries into one entry in the via header
446SHOULD NOT14.45combine multiple entries unless they are all under the same organizations control and the hosts have already been pseudonymized
447MUST NOT14.45combine multiple entries in the via header with different protocol values
448MAY14.46have responses with more than 1 warning header
449SHOULD14.46generate warn-text in the natural language most likely to be intelligble to the user receiving the response
450MAY14.46decide on the language for warnings using ANY available knowledge
451MUST14.46if sending a warning in a charset other than ISO-8859-1 encode it as per rfc 2047
452SHOULD14.46add new warning headers after existing warning headers
453MUST NOT14.46delete a warning it receives with a given message
454SHOULD14.46remove any warning headers associated with a cached response after successful validation (except as specified for some warning codes)
455MUST14.46add any warning headers received in validation responses to cached responses
456MUST14.46generate warning 110 on stale responses
457MUST14.46generate warning 111 on stale responses sent when revalidation failed
458SHOULD14.46generate warning 112 if we are offline intentionally for any length of time
459MUST14.46generate warning 113 if our heuristic chose a freshness lifetime > 24 hours and the response's age is >24 hours
460MAY14.46include and arbitrary info we want logged or presented to the user in a Warning 199
461MUST14.46generate warning 214 if we change the content-coding or media-type of the response unless this warning is already in the response
462MAY14.46include and arbitrary info we want logged or presented to the user in a Warning 299
463MUST14.46include a warn-date that matches the Date in the response in messages sent with warning headers whose version is HTTP/1.0 or lower
464MUST14.46delete warning-values that have a warn-date differing form the Date value in the response
465MUST14.46delete the warning header if it is empty
466MUST14.47include WWW-Authenticate in 401 responses
467SHOULD15.1be careful not to disclose personal information of the clients
468SHOULD15.1.2be able to filter/alter the From field when acting as a gateway
469SHOULD19.3assume RC 850 dates more than 50 years in the future are in the past
470MAY19.3"internally represent an Expires date as earlier than the proper value, but MUST NOT represent it as later than the proper value"
471MUST19.3do date calculations in GMT
472MUST19.3convert HTTP header dates to GMT using the most conservative possible conversion if they are not in GMT
473idea19.5.1sanitise the content-disposition header by removing directory information