HTTP/1.1 requirements checklist. (Complete barring a review for errors (no timeline on that:-]).)
| This document is not meant to replace rfcs 2616 and 2617 it is meant to act as a quick reference to the explicit requirements OTHER THAN THE BNF semantics that rfc 2616 requires. Conformance with the BNF is also required to meet http/1.1 compliance. Some minor SHOULD and MAY requirements which are not applicable to squid, or of use only once HTTP/1.1 compliance is achieved have been omitted. They will not impact squid's HTTP/1.1 base operation as a HTTP/1.1 proxy. Advanced features such as content type filtering may be impacted however. |
| Excel version: | squid-http1.1.xls |
| Tab delimited: | squid-http1.1.tsv |
| ID | Requirement type | section | requirement | squid status | tickmark | notes |
| 1 | REQUIRED | 2.1 | handle implied LWS = [CRLF] 1*( SP | HT ) | should do now | ||
| 2 | REQUIRED | 2.2 | fold CRLF in headers into one long header before interpreting | should do now | ||
| 3 | MUST | 3.1 | parse HTTP-Version as two multi-digit integers | unknown | ||
| 4 | SHOULD | 3.1 | send HTTP/1.1 in messages once we are conditionally compilent | not done | ||
| 5 | MUST | 3.1 | send HTTP/1.1 in messages that are not compatible with HTTP/1.0 | not done | ||
| 6 | MUST NOT | 3.1 | send HTTP versions greater than that of squid itself. (squid will be 1.1 when and only when it is conditionally compliant with rfc 2616 | does now | when we support all of http/1.1 send http/1.1 | |
| 7 | MUST | 3.1 | downgrade requests from greater than squid supports to what squid supports, return an error, or switch to tunnel behaviour | not done | hno - 7: Done, by simply downgrading the protocol number.
No attempts in downgrading the request is done |
|
| 8 | MUST | 3.1 | upgrade client requests to the highest version of HTTP supported by squid. | not done | conversion may involve altering header fields in ways that break the versions involved; HNO - 8: Does now. HTTP/0.9 is upgraded to HTTP/1.0 if support for 0.9 is enabled (and fixed). | |
| 9 | MUST | 3.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 | not done | hno - all responses from swuid are in squids current http version | |
| 10 | MUST | 3.2.1 | handle the URI of any resource served out (read proxied) | unknown | ||
| 11 | SHOULD | 3.2.1 | handle unbounded length URI's if we allow long GET requests | not done | we set an upper limit on URI's | |
| 12 | SHOULD | 3.2.1 | return 414 for URI's longer than we can actually handle | not done | use caution handling URI's more than 255 bytes long - old clients or downstream proxies may break. Hno - we currently return some other error code | |
| 13 | SHOULD | 3.2.2 | avoid using ip address's in generated URL's | does now | squids host name is used | |
| 14 | MUST | 3.2.2 | add / to http urls that have no abs_path; and if generating requests include the / | not done | done when sending to origin, not when sending to another proxy | |
| 15 | MUST NOT | 3.2.2 | change the hostname in a request with a FQDN in it | not done | redirectors can violate this | |
| 16 | MAY | 3.2.2 | add squids domain to the hostname that are not fully qualified in requests received by squid | does now | configure squid with append_domain | |
| 17 | SHOULD | 3.2.3 | compare URI's by case-sensitive octet-by-octet comparioson of the entire URI. | not done | empty or absent ports are equivalent to the default for that resource; empty abs_path ="/" | |
| 18 | MUST | 3.2.3 | compare hostnames in URI's case-insensitively | not done | ||
| 19 | MUST | 3.2.3 | compare scheme names in URI's case-insensitively | not done | ||
| 20 | MUST | 3.2.3 | match % HEX HEX encoded characters with those outside the reserved and unsafe sets when comparing URI's | unknown | ie http://abc.com:80/~smith/home.html; http://ABC.com/%7Esmith/home.html; http://ABC.com:/%7esmith/home.html match | |
| 21 | MUST | 3.3.1 | handle the three date formats of HTTP/1.0 | should do now | robustness is encouraged :-] | |
| 22 | MUST | 3.3.1 | only generate dates in rfc 1123 format | should do now | ||
| 23 | MUST | 3.3.1 | generate all dates in GMT (UTC) time. | should do now | ||
| 24 | MUST | 3.3.1 | assume GMT time when reading asctime format | should do now | ||
| 25 | MUST | 3.3.1 | not add LWS to the HTTP-date format other than that specifically included in the grammer | should do now | ||
| 26 | MUST | 3.4 | specify the mapping assocaited with a MIME character set name when using MIME character sets | not done | error pages should specify the charset & possibly other places | |
| 27 | SHOULD | 3.4 | limit the use of MIME character sets to IANA registry defined character sets | not done | ||
| 28 | MAY | 3.4.1 | include a charset parameter even when the charset is ISO-8559-1 | not done | ||
| 29 | SHOULD | 3.4.1 | include a charset parameter even when the charset is ISO-8559-1 when we know we will not confuse the client | not done | ||
| 30 | MUST | 3.4.1 | for the 'client' respect the charset label provided by the sender. | not done | ||
| 31 | SHOULD NOT | 3.5 | create responses with Content-Encoding: identity | should do now | ||
| 32 | SHOULD | 3.5 | register new content-coding value tokens with IANA | na | ||
| 33 | SHOULD | 3.5 | make publicly available specifications for new content-coding value tokens which conform to the purpose of content coding as per section 3.5 | na | ||
| 34 | MUST | 3.6 | when a transfer-coding is applied, include "chunked" in the set of transfer codings unless the message is terminated by closing the connection. | not done | hno - check the te branch | |
| 35 | MUST NOT | 3.6 | applied "chunked" more than once to a message-body | not done | hno - check the te branch | |
| 36 | SHOULD | 3.6 | register new transfer-encodings with IANA (as per section 3.5 for content-codings | na | ||
| 37 | SHOULD | 3.6 | return 501 and close the connection when client entity-bodies are received that squid doesn't understand the transfer-codings of. | not done | hno - check the te branch | |
| 38 | MUST NOT | 3.6 | send transfer-codings (TE or Transfer-Encoding headers) to HTTP/1.0 clients | not done | hno - check the te branch | |
| 39 | OPTIONAL | 3.6.1 | send a trailer after sending chunked transfer encoded messages | not done | hno - check the te branch | |
| 40 | MUST NOT | 3.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) | not done | hno - check the te branch | |
| 41 | MUST | 3.6.1 | understand "chunked" transfer-coding | not done | hno - check the te branch | |
| 42 | MUST | 3.6.1 | ignore chunk-extensions not understood | not done | hno - check the te branch | |
| 43 | MUST NOT | 3.7 | use LWS between the type and sub type in media-types, or between attribute and values | does now | for squid generated headers | |
| 44 | SHOULD | 3.7 | when sending to older applications (< HTTP/1.1) only use media types when required by the type/subtype definition | not done | ||
| 45 | MUST | 3.7.1 | represent entity-bodies in canonical media-type form (except "text" types). | does now | see rfc 2616 section 3.7.1 | |
| 46 | MUST | 3.7.1 | represent entity-bodies in canonical media-type form (except "text" types) prior to content-coding them | does now | see rfc 2616 section 3.7.1 | |
| 47 | MUST | 3.7.1 | label data in charsets other than ISO-8859-1" with an appropriate charset value. | not done | see rfc 2616 section 3.4.1 for compatability notes | |
| 48 | MUST | 3.7.2 | include a boundary parameter as part of the media type value for multipart media types | unknown | hno - squid does not generate or touch mulipart entries. Rbc - we may need to with TE content. Ermm, | |
| 49 | MUST | 3.7.2 | only use CRLF in multipart messages to represent line breaks between body-parts. | unknown | hno - squid does not generate or touch mulipart entries. Rbc - we may need to with TE content. Ermm, | |
| 50 | MUST | 3.7.2 | have the epilogue of multipart messages empty | unknown | hno - squid does not generate or touch mulipart entries. Rbc - we may need to with TE content. Ermm, | |
| 51 | MUST NOT | 3.7.2 | transmit the epligoue of multipart messages (even if given one) | unknown | hno - squid does not generate or touch mulipart entries. Rbc - we may need to with TE content. Ermm, | |
| 52 | SHOULD | 3.7.2 | follow the same behaviour as a MIME agent when receiving a multipart message-body. | unknown | ||
| 53 | MUST | 3.7.2 | treat unrecognized multipart subtypes as "multipart/mixed" | unknown | nb see rfc 1867 for multipart/form-data definition | |
| 54 | SHOULD | 3.8 | use short to the point product-tokens | unknown | ||
| 55 | MUST NOT | 3.8 | use product tokens for advertising or non-essential info | unknown | ||
| 56 | MAY | 3.8 | use any token character in a product-version | unknown | ||
| 57 | SHOULD | 3.8 | only use product-version tokens for a specific version | unknown | ||
| 58 | SHOULD | 3.8 | only change the product-version portion of a product value when changing version numbers | unknown | ||
| 59 | MUST NOT | 3.9 | generate more than 3 digits after the decimal point in quality values | unknown | ||
| 60 | SHOULD | 3.9 | limit user configuration to 3 digits on quality values | unknown | ||
| 61 | MUST | 3.10 | use rfc 1766 language tags in the accept-language and content-language fields | unknown | ||
| 62 | MAY | 3.11 | provide the same "strong" entity tag for two resources only if they are equivalent by octet equality | unknown | ||
| 63 | MAY | 3.11 | provide the same "weak" entity tag for two resources only if they are equivalent and can be substituted with no significant semantic changes | unknown | ||
| 64 | MUST | 3.11 | when giving entity tags provide unique entity tags for all versions of entities associated wth a particular resource | unknown | ||
| 65 | MAY | 3.11 | provide the same entity tag value for different resource URIs - note that this does no imply entity equivalnce across resources | unknown | ||
| 66 | MAY | 3.12 | ignore unrecognized ranges specified with units other than "bytes" | unknown | ||
| 67 | SHOULD | 4.1 | ignore empty lines where the Request-Line is expected | unknown | ||
| 68 | MUST NOT | 4.1 | preface or follow a request with an extra CRLF | unknown | ||
| 69 | MAY | 4.2 | precede header field values with LWS - although a single SP is preferred | unknown | ||
| 70 | MUST | 4.2 | precede extra lines in header fields with a single SP or HT | unknown | ||
| 71 | MAY | 4.2 | replace LWS in field values with a single SP | unknown | ||
| 72 | MAY | 4.2 | remove leading or trailing LWS on header fields | unknown | ||
| 73 | recommendation | 4.2 | send general-headers, then request/response headers, and then entity-headers | unknown | ||
| 74 | MUST | 4.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 | unknown | ||
| 75 | MUST NOT | 4.2 | alter the order on multiple message headers with the same field-name | unknown | ||
| 76 | MUST | 4.3 | use Transfer-Encoding to indicate any transfer encodings used when transmitting messages. | unknown | ||
| 77 | MAY | 4.3 | add 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 | unknown | ||
| 78 | MUST NOT | 4.3 | include a message-body in a request if the request-method does not allow it | unknown | ||
| 79 | SHOULD | 4.3 | read and forward message-bodies on any request | unknown | ||
| 80 | SHOULD | 4.3 | ignore message-bodies when semantics for the requests method do not define a message-body | unknown | ||
| 81 | MUST NOT | 4.3 | include a message-body in a response to a HEAD request | unknown | ||
| 82 | MUST NOT | 4.3 | include a message body in 1xx, 204 and 304 reponses | unknown | ||
| 83 | MUST | 4.3 | include a message body in all other responses, although it MAY be zero length | unknown | ||
| 84 | MUST | 4.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) | unknown | ||
| 85 | MUST NOT | 4.4 | send a Content-Length header if the entity-length and the transfer-length are not equal | unknown | ||
| 86 | MUST | 4.4 | ignore the Content-Length header if a Transfer-Encoding header is received | unknown | ||
| 87 | MUST NOT | 4.4 | send media type multipart/byteranges unless we know the recipient can parse it. | unknown | the presence of a Range header with multiple byte-range specifiers from a 1.1 client implies that the client can parse these reponses | |
| 88 | MUST | 4.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 | unknown | ||
| 89 | MUST | 4.4 | include a Content-Length header in requests containing a message body unless the server is known to be 1.1 compliant. | unknown | ||
| 90 | SHOULD | 4.4 | return 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 | unknown | ||
| 91 | MUST NOT | 4.4 | include both Content-Length and a non-identity transfer coding. | unknown | ||
| 92 | MUST | 4.4 | ignore the Content-Length header if a non-identity Transfer-Encoding is received. (perhaps covering for TE instead of Transfer-Encoding??) | unknown | ||
| 93 | MUST | 4.4 | IF 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. | unknown | ||
| 94 | MUST | 4.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 | unknown | ||
| 95 | MUST | 4.5 | treat unrecognized header fields as enitity header fields | unknown | ||
| 96 | SHOULD | 5.1.1 | return 405 if a request method is recognized but not allowed | unknown | ||
| 97 | SHOULD | 5.1.1 | return 501 if a request method is not implemented | unknown | ||
| 98 | MUST | 5.1.1 | support GET and HEAD for squid generated pages | unknown | ||
| 99 | MUST | 5.1.1 | implementh other methods beyond GET and HEAD in accordance with rfc 2616 | unknown | ||
| 100 | MUST | 5.1.1 | recognize all squid server names, including any aliases, local variations, and the numeric IP address | unknown | ||
| 101 | MUST | 5.1.1 | accept absolute URI's for all requests. | unknown | ||
| 102 | MAY | 5.1.1 | forward requests to other proxies or to the origin server. | should do now | ||
| 103 | MUST | 5.1.2 | decode URI's with % HEX HEX format before interpreting the request. | unknown | ||
| 104 | SHOULD | 5.1.2 | return appropriate status codes to invalid Request-URIs | unknown | ||
| 105 | MUST NOT | 5.1.2 | in transparent mode; rewrite the abs_path in thr Request-URI (ither than replacing a null abs_path with "/") | unknown | ||
| 106 | MUST | 5.2 | for absolute Request-URI's ignore any host header field in the request | unknown | ||
| 107 | MUST | 5.2 | for non-absolute Request-URI's with a host header use the host head field value | unknown | ||
| 108 | MUST | 5.2 | for non-absolute Request-URI's with no host header return 400 | unknown | ||
| 109 | MUST NOT | 5.2 | generate responses with CR or LF except at the end of the status line | unknown | ||
| 110 | MUST | 6.1 | understand the class of status codes (the 1st digit) and treat unrecognized responses as x00. | unknown | ||
| 111 | MUST NOT | 6.1 | cache responses with unrecognized status codes | unknown | ||
| 112 | MAY | 7 | transmit an entity if not otherwise restricted by the request method or response code | unknown | ||
| 113 | MUST | 7.1 | in transparent mode: forward unrecognized header fields | unknown | ||
| 114 | SHOULD | 7.2.1 | include a Content-Type header for generated HTTP/1.1 messages w/entity bodies | unknown | ||
| 115 | SHOULD | 7.2.1 | treat unknown media-types as application/octet-stream | unknown | ||
| 116 | SHOULD | 8.1.1 | implement HTTP/1.1 persistent connections | unknown | ||
| 117 | SHOULD | 8.1.2 | assume http/1.1 servers will maintain persistent connections even after error responses from the server | unknown | ||
| 118 | MUST NOT | 8.1.2 | send more requests on a connection afer a close is signaled | unknown | ||
| 119 | MAY | 8.1.2.1 | Assume a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header with token close was received in the request | unknown | ||
| 120 | SHOULD | 8.1.2.1 | Send a Connection header with token close if we want to close the client side connection immediately after sending the response | unknown | ||
| 121 | MAY | 8.1.2.1 | expect a connection to remain open - but decide based on the server response (does it have a connection header with token close)? | unknown | ||
| 122 | SHOULD | 8.1.2.1 | send a Connection header with token close if we want to only send one request and then close the server side connection | unknown | ||
| 123 | SHOULD NOT | 8.1.2.1 | assume a persistent connection is maintained for pre-HTTP/1.1 versions unless it is explicitly signlaed. | unknown | ||
| 124 | MUST | 8.1.2.1 | always create messages with self-defined message lengths | unknown | ||
| 125 | MAY | 8.1.2.2 | pipeline requests to upstream servers | unknown | ||
| 126 | MUST | 8.1.2.2 | send reponses to pipelined requests in the order that the requests were received | unknown | ||
| 127 | SHOULD | 8.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 | unknown | ||
| 128 | MUST NOT | 8.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 | unknown | ||
| 129 | MUST | 8.1.2.2 | be prepared to resend requests if a server closes the connection before sending all the pipelined requests | unknown | ||
| 130 | SHOULD NOT | 8.1.2.2 | pipeline non idempotent methods or non-idempotent sequences of methods. | unknown | ||
| 131 | SHOULD | 8.1.2.2 | wait to send non-idempotent requests after receiving the reponse status for the previous request | unknown | note: this may be a non-issue for us. | |
| 132 | recommendation | 8.1.3 | implement the Connection header field properly | unknown | ||
| 133 | MUST | 8.1.3 | signal persistent connections separately with clients and upstream servers | unknown | ||
| 134 | MUST NOT | 8.1.3 | establish a HTTP/1.1 persistent connection with a HTTP/1.0 client | unknown | ||
| 135 | SHOULD | 8.1.4 | issue a graceful close on the transport connection when timing out persistent connections | unknown | ||
| 136 | SHOULD | 8.1.4 | watch persistent connections for close signals and respond to it as appropriate | unknown | ||
| 137 | MAY | 8.1.4 | close any connection at any time. | unknown | ||
| 138 | MUST | 8.1.4 | be able to recover from asynchronous close events. | unknown | ||
| 139 | SHOULD | 8.1.4 | after an asynchronous close event reopen the transport connection and retransmit the aborted sequence automatically as long as the request is idempotent | unknown | ||
| 140 | MUST NOT | 8.1.4 | after an asynchronous close event reopen the transport connection and retransmit the aborted sequence automatically if the request is non-idempotent | unknown | ||
| 141 | SHOULD | 8.1.4 | always respond to at least one request per connection if possible | unknown | ||
| 142 | SHOULD NOT | 8.1.4 | close a connection in the middle of transmitting a response, unless network or client failure is suspected | unknown | ||
| 143 | SHOULD | 8.1.4 | for the client program - limit the number of silmutaneous connections maintained to a given server. | unknown | ||
| 144 | SHOULD NOT | 8.1.4 | for the client program - maintain more than 2 connections with any given server or proxy | unknown | ||
| 145 | SHOULD | 8.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 | unknown | ||
| 146 | SHOULD | 8.2.1 | maintain persistent connections and use TCP flow control to resolve link congestion rather than terminating connections abruptly | unknown | ||
| 147 | SHOULD | 8.2.2 | when sending message-bodies monitor the net connection for error's. | unknown | ||
| 148 | SHOULD | 8.2.2 | when sending message-bodies and a net error is detected immediately cease transmitting the body. | unknown | ||
| 149 | MAY | 8.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 | unknown | ||
| 150 | MUST | 8.2.2 | when sending message-bodies preceded by a content-length header and a net error is detected immediately cease transmitting the body and close the connection | unknown | ||
| 151 | MUST | 8.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 | unknown | ||
| 152 | MUST NOT | 8.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 | unknown | ||
| 153 | SHOULD NOT | 8.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 | unknown | ||
| 154 | MUST | 8.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 | unknown | ||
| 155 | MUST NOT | 8.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. | unknown | ||
| 156 | MAY | 8.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 | unknown | ||
| 157 | MAY | 8.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) | unknown | ||
| 158 | MUST NOT | 8.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 | unknown | ||
| 159 | SHOULD NOT | 8.2.3 | for the squid 'server' - send a 100 continue status if the request header does not include an Expect request header with the 100-continue expectation | unknown | ||
| 160 | MUST NOT | 8.2.3 | for the squid 'server' - send a 100 continue status if the request comer from a pre HTTP/1.1 client. | unknown | ||
| 161 | MAY | 8.2.3 | for 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 | unknown | ||
| 162 | MAY | 8.2.3 | for the squid 'server' - omit a 100 continure status if some or all of the request body has already been received | unknown | ||
| 163 | MUST | 8.2.3 | for the squid 'server' - send a final status code after one or more 100 codes, unless the transport connection is terminated prematurely | unknown | ||
| 164 | SHOULD NOT | 8.2.3 | for 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 | unknown | ||
| 165 | MUST | 8.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 | unknown | ||
| 166 | MUST NOT | 8.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 | unknown | ||
| 167 | MUST | 8.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 respond with 417 status | unknown | ||
| 168 | SHOULD | 8.2.3 | cache the http version of recently access next hop servers | unknown | ||
| 169 | MUST NOT | 8.2.3 | forward 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 | unknown | ||
| 170 | SHOULD | 8.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" | unknown | I don't know what the the "directly.. Really means" | |
| 171 | MAY | 8.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 | unknown | ||
| 172 | SHOULD NOT | 8.2.4 | continue retring requests as per rfc 8.2.4 when an error status is received | unknown | ||
| 173 | SHOULD | 8.2.4 | close 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) | unknown | ||
| 174 | MUST | 9 | send the Host request-header field with ALL HTTP/1.1 requests | unknown | ||
| 175 | SHOULD NOT | 9.1.1 | use GET and HEAD methods for anything other than retrieval (no side effects by squid) | unknown | ||
| 176 | SHOULD NOT | 9.1.2 | have side effects caused when receiving requests to squid with OPTIONS or TRACE as the method | unknown | ||
| 177 | MUST NOT | 9.2 | cache the results from an OPTIONS request | unknown | ||
| 178 | MUST | 9.2 | for the client program - include a content type field when sending an OPTIONS request with an entity body | unknown | ||
| 179 | MAY | 9.2 | for the squid 'server' - discard the request body from OPTIONS requests | unknown | ||
| 180 | SHOULD | 9.2 | 200 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) | unknown | ||
| 181 | SHOULD | 9.2 | 200 responses to the method OPTIONS with a message body should include information about the communications options | unknown | ||
| 182 | MAY | 9.2 | use content-negotiation to select the format for information about the message body in 200 responses to the method OPTIONS | unknown | ||
| 183 | MUST | 9.2 | include a Content-length header value of 0 or a reponse body in 200 responses to the method OPTIONS | unknown | ||
| 184 | MAY | 9.2 | for the client program - use the Max-Forwards request-header to target a specific proxy in the request chain. | unknown | ||
| 185 | MUST | 9.2 | check for a Max-Forwards field when squid recieves an OPTIONS request on an absoluteURI for which request forwarding is permitted | unknown | ||
| 186 | MUST NOT | 9.2 | forward 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. | unknown | ||
| 187 | SHOULD | 9.2 | response 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. | unknown | ||
| 188 | MUST | 9.2 | decrement 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. | unknown | ||
| 189 | MUST NOT | 9.2 | add a Max-Forwards header to an OPTIONS request if non is present when squid recieves it | unknown | ||
| 190 | MUST NOT | 9.3 | cache a GET response if it does not meet the HTTP caching requirements from rfc 2616 section 13 | unknown | ||
| 191 | MUST NOT | 9.4 | for the squid 'server' - generate a message-body in HEAD responses | unknown | ||
| 192 | SHOULD | 9.4 | for the squid 'server' - generate identical http headers for a HEAD request to the equivalent GET request. | unknown | ||
| 193 | MAY | 9.4 | update previously cached entities with the headers from a HEAD requests' response | unknown | ||
| 194 | MUST | 9.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) | unknown | ||
| 195 | MUST | 9.5 | follow the section 8.2 message transmission requirements for POST requests | unknown | ||
| 196 | MUST NOT | 9.5 | cache POST responses unless they include appropriate cache-control or Expires headers | unknown | ||
| 197 | SHOULD | 9.6 | for the squid 'server' - handling PUT requests - I skipped these as the cachmgr interface has not file storage capability | unknown | ||
| 198 | SHOULD | 9.6 | treat any cached entities that match the Request URI of a PUT request as stale | unknown | ||
| 199 | MUST | 9.6 | follow the section 8.2 message transmission requirements for PUT requests | unknown | ||
| 200 | MUST NOT | 9.6 | cache responses to PUT Method requests | unknown | ||
| 201 | SHOULD | 9.7 | for the squid 'server' - handling DELETE requests - I skipped these as the cachmgr interface has not file storage capability | unknown | maybe we could use DELETE squid-server/http///originaluri to allow removal of cached entities via the web? | |
| 202 | SHOULD | 9.7 | treat any cached entities that match the Request URI of a DELETE request as stale | unknown | ||
| 203 | MUST NOT | 9.7 | cache responses to DELETE Method requests | unknown | ||
| 204 | MUST NOT | 9.8 | for the squid client - create TRACE requests with an entity | unknown | ||
| 205 | SHOULD | 9.8 | reflect 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 | unknown | ||
| 206 | MUST NOT | 9.8 | cache responses to TRACE Method requests | unknown | ||
| 207 | MUST NOT | 10.1 | for the squid 'server' - send 1xx response codes to < HTTP/1.1 clients | unknown | ||
| 208 | MUST | 10.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 | unknown | ||
| 209 | MUST | 10.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 | unknown | ||
| 210 | SHOULD | 10.1.1 | for the client when getting a 100-continue reponses should continue with the request or ignore if the request has been completed. | unknown | ||
| 211 | MUST | 10.1.1 | for the squid 'server' - send a final reponse after handling the request | unknown | ||
| 212 | SHOULD | 10.1.2 | only upgrade protocols when it is advantageous to do so. | unknown | ||
| 213 | MUST | 10.2.2 | for the squid 'server' - handling PUT requests - I skipped these as the cachmgr interface has not file storage capability | unknown | ||
| 214 | MUST | 10.2.5 | teminate 204 responses by the first empty line after the header field | unknown | ||
| 215 | MUST NOT | 10.2.6 | include entities in 205 responses | unknown | ||
| 216 | MUST NOT | 10.2.7 | combine 206 responses with older content for the same entity unless the Etag or Last-Modified headers match exacly | unknown | ||
| 217 | MUST NOT | 10.2.7 | cache 206 reponses unless we support Range and Content-Range headers | unknown | ||
| 218 | MUST | 10.2.7 | include 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 | unknown | ||
| 219 | MUST | 10.2.7 | 206 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 | unknown | ||
| 220 | SHOULD | 10.3.2 | cache 301 responses unless otherwise indicated | unknown | ||
| 221 | MUST NOT | 10.3.2 | cache 301 responses to requests other than GET or HEAD | unknown | ||
| 222 | MUST NOT | 10.3.3 | cache 302 responses unless indicated by a Cache-Control or Expires header | unknown | ||
| 223 | MUST NOT | 10.3.3 | cache 302 responses to requests other than GET or HEAD | unknown | ||
| 224 | MUST NOT | 10.3.4 | cache 303 responses | unknown | ||
| 225 | MUST | 10.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 | unknown | ||
| 226 | MUST | 10.3.5 | when a 304 response indicates a not-currently-cached entity, disregard the response and repeat the request with no conditions | unknown | ||
| 227 | MUST | 10.3.5 | when a 304 response is received for a currently cached entity, update the entry with new field values given in the response | unknown | ||
| 228 | MUST | 10.3.6 | when a 305 response is received, repeat that _single_ request via the proxy in 'Location' | unknown | note: is this mean for squid to do , or only for the client? What about clients behind firewalls that can only use squid? | |
| 229 | MUST NOT | 10.3.6 | generate 305 responses except from the squid 'server' | unknown | ||
| 230 | MUST NOT | 10.3.7 | use the 306 status code | unknown | ||
| 231 | SHOULD NOT | 10.4.1 | retry requests where 400 was returned unless the client retries | unknown | ||
| 232 | SHOULD NOT | 10.4.4 | retry requests where 403 was returned | unknown | ||
| 233 | MUST | 10.4.6 | include an Allow header listing valid methods for requests where squid creates a 405 method to the client | unknown | ||
| 234 | MUST | 10.4.8 | return a Proxy-Authenticate header containing a challenge applicable to squid for the requested resource. | unknown | ||
| 235 | MAY | 10.4.9 | retry 408 requests | unknown | ||
| 236 | SHOULD NOT | 10.4.10 | retry 409 responses automatically | unknown | ||
| 237 | SHOULD | 10.4.11 | cache 410 responses | unknown | we should purge cached entity bodies that receive 410 responses. | |
| 238 | MAY | 10.4.12 | automatically retry a request with a Content-Length header in response to a 411 error | unknown | ||
| 239 | MAY | 10.4.12 | return 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 | unknown | ||
| 240 | MAY | 10.4.14 | return a 413 error when the request entity is too large. | unknown | ||
| 241 | SHOULD | 10.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 | unknown | ||
| 242 | SHOULD | 10.4.18 | return 417 when we have unambigous evidence that the expectation given in a request can not be met by the next hop server | unknown | ||
| 243 | SHOULD | 10.5 | include an entity body when we create 5xx error reponses explaining the issue (other than to HEAD requests) | unknown | ||
| 244 | SHOULD | 10.5.2 | return a 501 if we don't implement a given method and can't just proxy it an hope | unknown | ||
| 245 | SHOULD | 10.5.3 | return a 502 if we get an invalid upstream response | unknown | ||
| 246 | SHOULD | 10.5.4 | return a 503 if we are overloaded, or unable to serve requests due to maintenance. | unknown | ||
| 247 | MAY | 10.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 | unknown | ||
| 248 | SHOULD | 10.5.5 | return a 504 on an upstream timeout, or timeout on an auxilary server - ie DNS/authentication helper | unknown | nb we may be returning 400 or 500 presently | |
| 249 | MUST | 10.5.6 | return a 505 if we don't support, (or have #defed it out) the HTTP major version in the request message | unknown | ||
| 250 | OPTIONAL | 11 | implement basic and or digest authentication | unknown | ||
| 251 | MAY | 12 | use content-negotiation on any entity body request/response - ie in selecting what language the error should be in | unknown | ||
| 252 | MAY | 12.1 | for the squid client - include request header fields (Accept, Accept-Language, Accept-Encoding etc) in requests | unknown | ||
| 253 | MAY | 12.3 | develop transparent negotiation capabilities within HTTP/1.1 | unknown | ||
| 254 | recommendation | 13 | 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. | unknown | ||
| 255 | MUST | 13.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 | unknown | ||
| 256 | MAY | 13.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). | unknown | ||
| 257 | SHOULD | 13.1.1 | forward received responses even if the response itself is stale without adding a new Warning header | unknown | ||
| 258 | SHOULD NOT | 13.1.1 | attempt to revalidate responses that become stale in transit to squid | unknown | ||
| 259 | SHOULD | 13.1.1 | responsd as per the 13.1.1 respond rules even if the origin server cannot be contacted. | unknown | ||
| 260 | MUST | 13.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 | unknown | ||
| 261 | MUST | 13.1.2 | attach a warning noting when returning a response that is neither first-hand nor "fresh enough" using the Warning header | unknown | ||
| 262 | MUST | 13.1.2 | delete 1xx warnings from cached responses after succesful revalidation | unknown | ||
| 263 | MAY | 13.1.2 | generate 1xx warnings when validating a caced entry | unknown | ||
| 264 | MUST NOT | 13.1.2 | delete 2xx warning from cached responses after succesful revalidation | unknown | ||
| 265 | MAY | 13.1.2 | choose the warning text description language (perhaps based on Accept headers) | unknown | ||
| 266 | MAY | 13.1.2 | allow/create responses with multiple warnings, including multiple warnings with the same code | unknown | ||
| 267 | recommendation | 13.1.3 | use the most restrictive interpretation of caching issue /spec conflicts | unknown | ||
| 268 | MAY | 13.1.5 | have squid configurable to return stale responses even when not requested by clients | unknown | ||
| 269 | MUST | 13.1.5 | mark stale responses with a Warning header | unknown | ||
| 270 | SHOULD NOT | 13.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 | unknown | ie: offline mode, refresh to IMS are allowed but MUST require deliberate configuration by the admin | |
| 271 | SHOULD | 13.2.3 | be running on a host that uses NTP or equivalent for clock synchronization | na | ||
| 272 | MUST | 13.2.3 | calculate corrected_received_age as max(now-date_value, age_value) | unknown | ||
| 273 | MUST | 13.2.3 | interprest Age header values (age_value) relative to the time the request was initiated, not the response time. | unknown | ||
| 274 | MUST | 13.2.3 | calculate corrected_initial_age as corrected_received_age +(now - request_time) ; request_time = time the request was sent upstream | unknown | ||
| 275 | MUST | 13.2.3 | when sending responses from cached entries include a single Age header with a value equal to current_age (as per 13.2.3 algorithm) | unknown | ||
| 276 | MAY | 13.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 | unknown | ||
| 277 | MUST | 13.2.4 | attach a Warning 113 to any response when the age_value is more than 24 hours if there is no 113 warning already | unknown | ||
| 278 | SHOULD | 13.2.4 | use heuristics that use a fraction of the last-modified time (if it exists) - suggested setting of 10% since last-modified | unknown | ||
| 279 | MUST | 13.2.5 | when two responses exist for a given representation with different validators, use the one with the more recent Date header. | unknown | ie don't naively assume an incoming response is newer than the entity it is a refresh for | |
| 280 | SHOULD | 13.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 | unknown | note this is specced as a client requirement - but we have to implement client code as well. Does squid need to do this or let the client do it?? | |
| 281 | MUST NOT | 13.3.3 | use a weak validator in anything other than simple (non-subrange) GET requests | unknown | ||
| 282 | MUST | 13.3.3 | consider two validators strongly equal IFF both validators are identical, and both are NOT weak | unknown | ||
| 283 | MUST | 13.3.3 | consider two validators weakly equal IFF both validators are identical, and one or both are NOT strong | unknown | ||
| 284 | MUST | 13.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 | unknown | ||
| 285 | MUST | 13.3.3 | when receiving conditional requests the use strong comparison (no weak compares allowed) | unknown | ||
| 286 | MUST NOT | 13.3.4 | return 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 | unknown | ||
| 287 | MUST NOT | 13.3.4 | return 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 | unknown | ||
| 288 | MUST NOT | 13.3.5 | use other headers than entity tags and Last-Modified for validation | unknown | ||
| 289 | MAY | 13.4 | always cache a successful response (unless constrained by 14.9) | unknown | ||
| 290 | MAY | 13.4 | return cached responses without validation while fresh (unless constrained by 14.9) | unknown | ||
| 291 | MAY | 13.4 | return cached responses after succesful validation (unless constrained by 14.9) | unknown | ||
| 292 | MAY | 13.4 | cache responses with no validator or expiration time, but shouldn't do so in normal conditions | unknown | ||
| 293 | MAY | 13.4 | cache and use as replies, responses with status codes 200, 203, 206, 300, 301 or 410 (subject to expiration & cache-control mechanisms) | unknown | ||
| 294 | MUST NOT | 13.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 | unknown | ||
| 295 | MUST | 13.5.1 | store end to end headers (headers other than Connection; Keep-Alive ; Proxy-Authenticate ; Proxy-Authorization ; TE ; Trailers ; Transfer-Encoding ; Upgrade) with the cached response | unknown | ||
| 296 | MUST | 13.5.1 | transmit cached end to end headers in any response fromed from that cache entry | unknown | ||
| 297 | MUST | 13.5.1 | list newly defined hop to hop headers under the connection header | unknown | ||
| 298 | SHOULD NOT | 13.5.2 | modify end to end headers unless the definition of that header specifically allows or requires its modification | unknown | ||
| 299 | MUST NOT | 13.5.2 | as a transparent proxy; modify (Content-Location; Content-MD5;- Etag; Last-Modified; Expires) headers in a request or response | unknown | ||
| 300 | MAY | 13.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 | unknown | ||
| 301 | MUST NOT | 13.5.2 | as a transparent proxy; add (Content-Location; Content-MD5;- Etag; Last-Modified) headers in a request or response | unknown | ||
| 302 | MAY | 13.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" | unknown | ||
| 303 | MUST | 13.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" | unknown | ||
| 304 | MUST | 13.5.2 | as a transaprent proxy; preserve the entity-length of the entity body in a response/request | unknown | ||
| 305 | MAY | 13.5.2 | as a transaprent proxy; change the preserve the transfer-length in a response/request | unknown | ||
| 306 | MAY | 13.5.3 | combine 206 responses with cached content for the same entity as long as the Etag or Last-Modified headers match exactly | unknown | ||
| 307 | MUST | 13.5.3 | update any end-end headers in cache entries with those from a 304 or 206 response or remove the cache entry | unknown | ||
| 308 | MUST | 13.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 | unknown | ||
| 309 | MAY | 13.5.4 | combine byte ranges if both the incoming response and the cache entry have validotrs, and the validators match using the strong comparison | unknown | ||
| 310 | MUST | 13.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 | unknown | ||
| 311 | MUST NOT | 13.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 | unknown | ||
| 312 | MUST NOT | 13.5.6 | use a cache entry to construct a response to a request when the response had a Vary header of * without validation by the origin server | unknown | ||
| 313 | SHOULD | 13.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 | unknown | ||
| 314 | SHOULD NOT | 13.5.6 | include 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 | unknown | ||
| 315 | SHOULD | 13.5.6 | delete cache entries when a successful response with a matching Content-Location field, a differing entity-tag and a more recent Date | unknown | ||
| 316 | SHOULD NOT | 13.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 | unknown | ||
| 317 | MAY | 13.8 | store incomplete responses | unknown | ||
| 318 | MUST | 13.8 | treat incomplete responses as partial responses | unknown | ||
| 319 | MUST NOT | 13.8 | return a partial response to a client without marking it as such (using 206 status code) | unknown | ||
| 320 | MUST NOT | 13.8 | return a partial response to a client with status 200 | unknown | ||
| 321 | MAY | 13.8 | forward 5xx responses received while revalidating entries to the client, or act as if the server failed to respond | unknown | ||
| 322 | MAY | 13.8 | when a server fails to respond, return a cached response unless the cached entry inludes the must-revalidate cache-control directive | unknown | ||
| 323 | MUST NOT | 13.9 | treat GET and HEAD requests with ? In the URI path as fresh UNLESS explicit exipration times are provided in the repsonse | unknown | ||
| 324 | SHOULD NOT | 13.9 | cache GET and HEAD responses from HTTP/1.0 servers with ? In the URI path | unknown | ||
| 325 | MUST | 13.10 | invalidate 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 | unknown | ||
| 326 | SHOULD | 13.10 | invalidate entities referred to by the Request-URI in non understood methods if we pass them upstream | unknown | ||
| 327 | MUST | 13.11 | pass upstream all methods that may cause alterations to the origin servers resources. (This means all Methods other than GET and HEAD) | unknown | ||
| 328 | MUST NOT | 13.11 | respond 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. | unknown | ||
| 329 | MAY | 13.11 | respond 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. | unknown | ||
| 330 | SHOULD | 13.12 | when a new response to an existing cached resource arrives, use the new response to reply to the current request | unknown | ||
| 331 | MAY | 13.12 | when a new response to an existing cached resource arrives, update the cache with the new response | unknown | ||
| 332 | MAY | 13.12 | when a new response to an existing cached resource arrives, use it to respond to future requests as appropriate | unknown | ||
| 333 | MAY | 14.1 | include parameters for media types that support them | unknown | ||
| 334 | MAY | 14.1 | include accept-params for media types. (q=0 to q=1) (see 3.9) | unknown | ||
| 335 | SHOULD | 14.1 | for the squid 'server' send 406 if we cannot get an acceptable media type for the client request | unknown | ||
| 336 | MAY | 14.2 | have q values for charsets | unknown | ||
| 337 | SHOULD | 14.2 | for the squid 'server' send 406 if we cannot get an acceptable charset for the client request | unknown | ||
| 338 | MAY | 14.3 | have q values for content-coding | unknown | ||
| 339 | SHOULD | 14.3 | for 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 | unknown | ||
| 340 | MAY | 14.3 | assume the client will accept any content coding when to Accept-Encoding header is presented | unknown | ||
| 341 | SHOULD | 14.3 | for the squid 'server' send identity content-coding when no Accept-Encoding header is presented | unknown | ||
| 342 | MAY | 14.4 | have q values for preferred language | unknown | ||
| 343 | SHOULD | 14.4 | assume all languages are ok when there is no header | unknown | ||
| 344 | MAY | 14.5 | for the squid 'server' send Accept-ranges: none to tell clients not to attempt range requests | unknown | ||
| 345 | MUST | 14.6 | when an age header we receive is larger than our largest integer, or if an Age calculation overflows, transmit age of 2147483648 (2^31). | unknown | ||
| 346 | SHOULD | 14.6 | use integers of at least 31 bits | unknown | ||
| 347 | MUST | 14.7 | present an Allow header in 405 responses | unknown | ||
| 348 | MUST NOT | 14.7 | modify the allow header | unknown | ||
| 349 | SHOULD | 14.8 | have a set of credentials valid for an entire realm (including all sub-resources) (ie for web-accel operation) | unknown | ||
| 350 | MUST NOT | 14.8 | return 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 | unknown | ||
| 351 | MUST | 14.8 | always revalidate responses with cache-control: s-maxage=0 | unknown | ||
| 352 | MUST | 14.9 | follow the cache-control header directives at all times | unknown | ||
| 353 | MUST | 14.9 | pass cache-control directives through to the next link in the message path (ie don't eat them) | unknown | ||
| 354 | MAY | 14.9.1 | cache responses with cache-control: public even of the header/method might not normally be cacheable | unknown | ||
| 355 | MUST NOT | 14.9.1 | cache responses with cache-control: private | unknown | ||
| 356 | MUST NOT | 14.9.1 | use responses with cache-control: no-cache to satisfy other requests without successful revalidation | unknown | ie auto GET to IMS is allowed | |
| 357 | MAY | 14.9.1 | use responses with cache-control: no-cache to satisfy other requests without successful revalidation if the no-cache directive includes field-names | unknown | ||
| 358 | MUST NOT | 14.9.1 | send the headers listed in responses with cache-control: no-cache (header…) to satisfy other requests without successful revalidation if the no-cache directive includes field-names | unknown | ||
| 359 | MAY | 14.9.2 | use no-store on requests or responses to prevent data storage | unknown | ||
| 360 | MUST NOT | 14.9.2 | store any part of a request or it's response if the cache-control: no-store directive was in the request | unknown | This directive applies to both non-shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. | |
| 361 | MUST NOT | 14.9.2 | store any part of a response or the request that elicited it if the cache-control: no-store directive was in the response | unknown | This directive applies to both non-shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. | |
| 362 | SHOULD | 14.9.3 | consider responses with an Expires value that is <= the response date and no cache-control header field to be non-cacheable | unknown | ||
| 363 | MUST | 14.9.3 | mark stale responses with Warning 110 | unknown | ||
| 364 | MAY | 14.9.3 | have 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 | unknown | ||
| 365 | MUST NOT | 14.9.4 | use a cached copy to respond to a request with cache-control: no-cache or Pragma: no-cache | unknown | ||
| 366 | SHOULD | 14.9.4 | response 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 | unknown | ||
| 367 | MUST NOT | 14.9.4 | use stale responses marked with cache-control: must-revalidate after it becomes stale without first revalidating it with the origin | unknown | ||
| 368 | MUST | 14.9.4 | obey the must-revalidate directive at all times | unknown | ||
| 369 | MUST | 14.9.4 | return 504 if a must-revalidate directive would need access to an unavailable origin server | unknown | ||
| 370 | MUST NOT | 14.9.5 | change 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 | unknown | ||
| 371 | MUST | 14.9.6 | ignore unrecognized cache-control headers | unknown | ||
| 372 | MUST | 14.10 | parse the Connection header before a message is forwarded | unknown | ||
| 373 | MUST | 14.10 | remove headers from messages that match headers specified in the connection header | unknown | ||
| 374 | MUST NOT | 14.10 | list end to end headers in the connection header | unknown | ||
| 375 | MUST | 14.10 | for applications that do not support persistent connection (ie squid 'server' and client) include Connection: close in every message | unknown | ||
| 376 | MUST | 14.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 | unknown | ||
| 377 | MAY | 14.11 | as a NON-TRANSPARENT proxy modify content-coding to be more suitable to a client request | unknown | ||
| 378 | MUST | 14.11 | if the content encoding of an entity is not "identity" | unknown | ||
| 379 | MUST | 14.11 | list in applied order the content codings applied to an entity | unknown | ||
| 380 | MAY | 14.12 | list multiple languages in a Content-Language header if the reponse is intended for multiple audiences (perhaps a multi-lingual error page?) | unknown | ||
| 381 | SHOULD | 14.13 | use and send the Content-Length header unless prohibited by section 4.4 | unknown | ||
| 382 | MUST NOT | 14.15 | generate Content-MD5 headers | unknown | ||
| 383 | MAY | 14.15 | check Content-MD5 headers | unknown | ||
| 384 | MUST | 14.15 | remove transfer-encodings before checking the MD5 | unknown | ||
| 385 | MUST NOT | 14.15 | convert line breaks to CRLF before checking the MD5 | unknown | ||
| 386 | SHOULD | 14.16 | indicate the total length of the full entity body in Content-Range headers | unknown | ||
| 387 | MUST | 14.16 | only specify one range in byte-range-resp-spec | unknown | ||
| 388 | MUST | 14.16 | use absolute byte positions for byte-range-resp-spec values | unknown | ||
| 389 | MUST | 14.16 | ignore invalid byte-range-resp-spec and any content transferred with it | unknown | ||
| 390 | MUST NOT | 14.16 | have response code 206 with a byte-range-resp-spec of * | unknown | ||
| 391 | MUST | 14.18 | assign a Date header if we receive a message without one, | unknown | ||
| 392 | SHOULD | 14.18 | assign the best available approximation of the date and time of message generation when we assign Date headers | unknown | ||
| 393 | MAY | 14.19 | use Entitiy tags for comparison with other entities from the same resource | unknown | ||
| 394 | MUST | 14.21 | treat invalid Expires headers (NON RFC 1123 format) as being in the past | unknown | ||
| 395 | MAY | 14.22 | log the From header | unknown | ||
| 396 | SHOULD NOT | 14.22 | use the From header for access-control | unknown | ||
| 397 | MUST | 14.23 | for clients: include a Host header in all http/1.1 requests | unknown | ||
| 398 | MUST | 14.23 | for clients: include an empty Host header in all http/1.1 requests when no host name is available | unknown | ||
| 399 | MUST | 14.23 | ensure that all requests forwarded include an appropriate Host header | unknown | ||
| 400 | MUST | 14.23 | respond with 400 to http/1.1 requests missing a Host header | unknown | ||
| 401 | MUST | 14.24 | use the strong comparison when comparing entity tags for If-Match | unknown | ||
| 402 | SHOULD | 14.25 | return a 304 to IMS requests that have not been modified (using cached data if possible) | unknown | ||
| 403 | MUST | 14.31 | check and decrement (if greater than 0) the Max-Forwards header if present in TRACE and OPTIONS requests | unknown | ||
| 404 | MUST | 14.31 | respond as the final recipient if the Max-Forwards header is 0 on a TRACE or OPTIONS request | unknown | ||
| 405 | MAY | 14.31 | ignore the Max-Forwards header for all other methods covered by rfc 2616 | unknown | ||
| 406 | SHOULD | 14.32 | forward requests with Pragme: no-cache upstream even if a cached copy exists | unknown | ||
| 407 | MUST | 14.32 | pass Pragma directives up/downstream in all cases | unknown | ||
| 408 | SHOULD | 14.32 | ignore pragma directives not relevant or understood by us | unknown | ||
| 409 | SHOULD | 14.32 | treat pragme: no-cache ascache-control: no-cache | unknown | ||
| 410 | MUST | 14.33 | include Proxy-Authenticate when sending a 407 response | unknown | note: NTLm auth requires an unrecommended order | |
| 411 | SHOULD NOT | 14.33 | pass Proxy-Authenticate downstrem | unknown | ||
| 412 | MAY | 14.34 | relay credentials from a client upstream to a parent cache (if that is the mechanism by which the two caches cooperatively authenticate a given request) | unknown | ||
| 413 | MAY | 14.35.1 | specify a single byte range or a set of ranges within a single entity with a single byte range operation | unknown | ||
| 414 | MUST | 14.35.1 | have the last-byte-pos value (if present) great than or equal to the first-byte-pos in the byte-range-spec | unknown | ||
| 415 | MUST | 14.35.1 | ignore a header field with an invalid byte-range-spec | unknown | ||
| 416 | SHOULD | 14.35.1 | return 416 if a byte-range-set is unsatisfiable | unknown | ||
| 417 | SHOULD | 14.35.1 | return 206 when returning ranges | unknown | ||
| 418 | MAY | 14.35.2 | for the client - request one or more subranges on conditional or un-conditional GET requests | unknown | ||
| 419 | MAY | 14.35.2 | ignore the range header. | unknown | We should support this, and should look at caching partial responses | |
| 420 | SHOULD | 14.35.2 | only return the requested range to a client even if we get given the entire entity in response to a request containing a range request | unknown | ||
| 421 | SHOULD | 14.35.2 | store 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 | unknown | ||
| 422 | MUST NOT | 14.36 | for the client - send a referer field if the request-URI was not obtained from a source with it's own URI - ie the keyboard | unknown | ||
| 423 | MAY | 14.37 | use Retry-After to indicate how long a client should wait before requesting the new location | unknown | ||
| 424 | MUST NOT | 14.38 | modify the Server header on forwarded responses | unknown | ||
| 425 | SHOULD | 14.38 | include a Via header on forwarded resposnes | unknown | ||
| 426 | MUST | 14.39 | include the TE connection token whenever we use TE on a connection | unknown | ||
| 427 | SHOULD NOT | 14.40 | include header fields in the trailer with having sent a Trailer header | unknown | ||
| 428 | MUST NOT | 14.40 | send Transfer-Encoding; Content-Length or Trailer as Trailer field values | unknown | ||
| 429 | MUST | 14.41 | list in the order applied the transfer-encodings applied to a response (ie rsync, gzip | unknown | ||
| 430 | MUST | 14.42 | use the upgrade header in a response with status code 101 | unknown | ||
| 431 | MUST | 14.42 | include the Upgrade connection-token whenever we use the Upgrade header | unknown | ||
| 432 | SHOULD | 14.43 | for the client - include a user-Agent field in requests | unknown | ||
| 433 | SHOULD | 14.44 | include a Vary header on any cacheable response we generate that used server negotiation | unknown | ||
| 434 | MAY | 14.44 | for the 'server' include a vary header with a non-cacheable resposne the used server negotiation | unknown | ||
| 435 | MAY | 14.44 | assume 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 | unknown | ||
| 436 | MUST NOT | 14.44 | generate a * value for a vary field | unknown | ||
| 437 | MUST | 14.45 | fill in the Via header | unknown | ||
| 438 | MAY | 14.45 | replace the host in the via header with a pseudonym for security/privacy | unknown | ||
| 439 | MUST | 14.45 | append our details to the Via header | unknown | ||
| 440 | MAY | 14.45 | remove comments from the via header before forwarding | unknown | ||
| 441 | MAY | 14.45 | put comments in the via header before forwarding | unknown | ||
| 442 | SHOULD NOT | 14.45 | when used as a gateway/ http firewall forward names/hosts/ports of hosts within the firewall | unknown | perhaps a config directive - firewall - turn on several things? | |
| 443 | SHOULD | 14.45 | require explicit enablement of forwarding names/hosts/ports of hosts within the firewall | unknown | perhaps a config directive - firewall - turn on several things? | |
| 444 | SHOULD | 14.45 | replace the received-by host with a pseudonym when used as a gateway/ http firewall forward names/hosts/ports of hosts within the firewall | unknown | ||
| 445 | MAY | 14.45 | for organisations with privacy concerns: collapse multiple protocol-value entries into one entry in the via header | unknown | ||
| 446 | SHOULD NOT | 14.45 | combine multiple entries unless they are all under the same organizations control and the hosts have already been pseudonymized | unknown | ||
| 447 | MUST NOT | 14.45 | combine multiple entries in the via header with different protocol values | unknown | ||
| 448 | MAY | 14.46 | have responses with more than 1 warning header | unknown | ||
| 449 | SHOULD | 14.46 | generate warn-text in the natural language most likely to be intelligble to the user receiving the response | unknown | ||
| 450 | MAY | 14.46 | decide on the language for warnings using ANY available knowledge | unknown | ||
| 451 | MUST | 14.46 | if sending a warning in a charset other than ISO-8859-1 encode it as per rfc 2047 | unknown | ||
| 452 | SHOULD | 14.46 | add new warning headers after existing warning headers | unknown | ||
| 453 | MUST NOT | 14.46 | delete a warning it receives with a given message | unknown | ||
| 454 | SHOULD | 14.46 | remove any warning headers associated with a cached response after successful validation (except as specified for some warning codes) | unknown | ||
| 455 | MUST | 14.46 | add any warning headers received in validation responses to cached responses | unknown | ||
| 456 | MUST | 14.46 | generate warning 110 on stale responses | unknown | ||
| 457 | MUST | 14.46 | generate warning 111 on stale responses sent when revalidation failed | unknown | ||
| 458 | SHOULD | 14.46 | generate warning 112 if we are offline intentionally for any length of time | unknown | ||
| 459 | MUST | 14.46 | generate warning 113 if our heuristic chose a freshness lifetime > 24 hours and the response's age is >24 hours | unknown | ||
| 460 | MAY | 14.46 | include and arbitrary info we want logged or presented to the user in a Warning 199 | unknown | ||
| 461 | MUST | 14.46 | generate warning 214 if we change the content-coding or media-type of the response unless this warning is already in the response | unknown | ||
| 462 | MAY | 14.46 | include and arbitrary info we want logged or presented to the user in a Warning 299 | unknown | ||
| 463 | MUST | 14.46 | include a warn-date that matches the Date in the response in messages sent with warning headers whose version is HTTP/1.0 or lower | unknown | ||
| 464 | MUST | 14.46 | delete warning-values that have a warn-date differing form the Date value in the response | unknown | ||
| 465 | MUST | 14.46 | delete the warning header if it is empty | unknown | ||
| 466 | MUST | 14.47 | include WWW-Authenticate in 401 responses | unknown | ||
| 467 | SHOULD | 15.1 | be careful not to disclose personal information of the clients | unknown | ||
| 468 | SHOULD | 15.1.2 | be able to filter/alter the From field when acting as a gateway | unknown | ||
| 469 | SHOULD | 19.3 | assume RC 850 dates more than 50 years in the future are in the past | unknown | ||
| 470 | MAY | 19.3 | internally represent an Expires date as earlier than the proper value, but MUST NOT represent it as later than the proper value | unknown | ||
| 471 | MUST | 19.3 | do date calculations in GMT | unknown | ||
| 472 | MUST | 19.3 | convert HTTP header dates to GMT using the most conservative possible conversion if they are not in GMT | unknown | ||
| 473 | idea | 19.5.1 | sanitise the content-disposition header by removing directory information | unknown |