🔗 Feature: Progress of the HTTP/1.1 conversion of Squid?

• Goal: To make Squid a full HTTP/1.1 proxy
• Status: Underway

🔗 Details

Information is not up to date. Empty entries need to be checked against in the code.

	Supported. Expect it to work. Verified by third-party testing. A minimum version may be indicated.
	Absent and needs to be done. Third-party tested. A last-tested version may be indicated.
	Developers expect hiss to work. Not third-party confirmed.
	Missing, but optional

2.x	3.x	ID	Requirement type	section	requirement	notes
		1	REQUIRED	2.1	handle implied ` LWS = [CRLF] 1*( SP | HT ) `
		2	REQUIRED	2.2	fold CRLF in headers into one long header before interpreting
		3	MUST	3.1	parse HTTP-Version as two multi-digit integers
		4	SHOULD	3.1	send HTTP/1.1 in messages once we are conditionally compliant
		5	MUST	3.1	send HTTP/1.1 in messages that are not compatible with HTTP/1.0
		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	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 behavior	Downgrades the protocol number and decodes TE. Few attempts in downgrading the request is done.
		8	MUST	3.1	upgrade client requests to the highest version of HTTP supported by squid.	conversion may involve altering header fields in ways that break the versions involved; HNO - 8: 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 response, regardless if squid is a 2.x proxy by that point	all 3.x responses from squid are in squids current http version. 2.x has upgrade_http0.9 which keeps 0.9 in their own major version.
		10	MUST	3.2.1	handle the URI of any resource served out (read proxied)
4KB	8KB	11	SHOULD	3.2.1	handle unbounded length URI’s if we allow long GET requests	we set an upper limit on URI’s
		12	SHOULD	3.2.1	return 414 for URI’s longer than we can actually handle	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	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 /	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	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	append_domain
		17	SHOULD	3.2.3	compare URI’s by case-sensitive octet-by-octet comparison of the entire URI.	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
		19	MUST	3.2.3	compare scheme names in URI’s case-insensitively
		20	MUST	3.2.3	match % HEX HEX encoded characters with those outside the reserved and unsafe sets when comparing URI’s	ie http://abc.com:80/~smith/home.html; http://ABC.com/~smith/home.html; http://ABC.com:/~smith/home.html match
		21	MUST	3.3.1	handle the three date formats of HTTP/1.0	robustness is encouraged
		22	MUST	3.3.1	only generate dates in rfc 1123 format
		23	MUST	3.3.1	generate all dates in GMT (UTC) time.
		24	MUST	3.3.1	assume GMT time when reading asctime format
		25	MUST	3.3.1	not add LWS to the HTTP-date format other than that specifically included in the grammar
		26	MUST	3.4	specify the mapping associated with a MIME character set name when using MIME character sets	error pages specify the charset & possibly other places
		27	SHOULD	3.4	limit the use of MIME character sets to IANA registry defined character sets
		28	MAY	3.4.1	include a charset parameter even when the charset is ISO-8559-1
		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.
		31	SHOULD NOT	3.5	create responses with Content-Encoding: identity	should do now
N/A	N/A	32	SHOULD	3.5	register new content-coding value tokens with IANA
N/A	N/A	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
		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.	hno - check the te branch
		35	MUST NOT	3.6	applied “chunked” more than once to a message-body	hno - check the te branch
N/A	N/A	36	SHOULD	3.6	register new transfer-encodings with IANA (as per section 3.5 for content-codings
		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.	hno - check the te branch
		38	MUST NOT	3.6	send transfer-codings (TE or Transfer-Encoding headers) to HTTP/1.0 clients	hno - check the te branch
		39	OPTIONAL	3.6.1	send a trailer after sending chunked transfer encoded messages	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)	hno - check the te branch
		41	MUST	3.6.1	understand “chunked” transfer-coding	hno - check the te branch
		42	MUST	3.6.1	ignore chunk-extensions not understood	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
		45	MUST	3.7.1	represent entity-bodies in canonical media-type form (except “text” types).
		46	MUST	3.7.1	represent entity-bodies in canonical media-type form (except “text” types) prior to content-coding them
		47	MUST	3.7.1	label data in charsets other than ISO-8859-1” with an appropriate charset value.	see rfc 2616 section 3.4.1 for compatibility notes
		48	MUST	3.7.2	include a boundary parameter as part of the media type value for multipart media types	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.	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	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)	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.
		53	MUST	3.7.2	treat unrecognized multipart subtypes as “multipart/mixed”	see rfc 1867 for multipart/form-data definition
		54	SHOULD	3.8	use short to the point product-tokens
		55	MUST NOT	3.8	use product tokens for advertising or non-essential info
		56	MAY	3.8	use any token character in a product-version
		57	SHOULD	3.8	only use product-version tokens for a specific version
		58	SHOULD	3.8	only change the product-version portion of a product value when changing version numbers
		59	MUST NOT	3.9	generate more than 3 digits after the decimal point in quality values
		60	SHOULD	3.9	limit user configuration to 3 digits on quality values
		61	MUST	3.10	use rfc 1766 language tags in the accept-language and content-language fields
		62	MAY	3.11	provide the same “strong” entity tag for two resources only if they are equivalent by octet equality
		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
		64	MUST	3.11	when giving entity tags provide unique entity tags for all versions of entities associated with a particular resource
		65	MAY	3.11	provide the same entity tag value for different resource URIs - note that this does no imply entity equivalence across resources
		66	MAY	3.12	ignore unrecognized ranges specified with units other than “bytes”
		67	SHOULD	4.1	ignore empty lines where the Request-Line is expected
		68	MUST NOT	4.1	preface or follow a request with an extra CRLF
		69	MAY	4.2	precede header field values with LWS - although a single SP is preferred
		70	MUST	4.2	precede extra lines in header fields with a single SP or HT
		71	MAY	4.2	replace LWS in field values with a single SP
		72	MAY	4.2	remove leading or trailing LWS on header fields
		73	recommendation	4.2	send general-headers, then request/response headers, and then entity-headers
		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
		75	MUST NOT	4.2	alter the order on multiple message headers with the same field-name
		76	MUST	4.3	use Transfer-Encoding to indicate any transfer encodings used when transmitting messages.
		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
		78	MUST NOT	4.3	include a message-body in a request if the request-method does not allow it
		79	SHOULD	4.3	read and forward message-bodies on any request
		80	SHOULD	4.3	ignore message-bodies when semantics for the requests method do not define a message-body
		81	MUST NOT	4.3	include a message-body in a response to a HEAD request
		82	MUST NOT	4.3	include a message body in 1xx responses
		82	MUST NOT	4.3	include a message body in 204 responses
		82	MUST NOT	4.3	include a message body in 304 responses
		83	MUST	4.3	include a message body in all other responses, although it MAY be zero length
		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)
		85	MUST NOT	4.4	send a Content-Length header if the entity-length and the transfer-length are not equal
		86	MUST	4.4	ignore the Content-Length header if a Transfer-Encoding header is received
		87	MUST NOT	4.4	send media type multipart/byteranges unless we know the recipient can parse it.	the presence of a Range header with multiple byte-range specifiers from a 1.1 client implies that the client can parse these responses
		88	MUST	4.4	delimit the response 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
		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.
		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
		91	MUST NOT	4.4	include both Content-Length and a non-identity transfer coding.
		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??)
		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.
		94	MUST	4.4	when sending a response where a message body is allowed and we include Content-Length, it’s value must match the number of OCTECTS in the message-body
		95	MUST	4.5	treat unrecognized header fields as enitity header fields
		96	SHOULD	5.1.1	return 405 if a request method is recognized but not allowed
		97	SHOULD	5.1.1	return 501 if a request method is not implemented
		98	MUST	5.1.1	support GET and HEAD for squid generated pages
		99	MUST	5.1.1	implementh other methods beyond GET and HEAD in accordance with rfc 2616
		100	MUST	5.1.1	recognize all squid server names, including any aliases, local variations, and the numeric IP address
		101	MUST	5.1.1	accept absolute URI’s for all requests.
		102	MAY	5.1.1	forward requests to other proxies or to the origin server.
		103	MUST	5.1.2	decode URI’s with % HEX HEX format before interpreting the request.
		104	SHOULD	5.1.2	return appropriate status codes to invalid Request-URIs
		105	MUST NOT	5.1.2	in transparent mode; rewrite the abs_path in the Request-URI (other than replacing a null abs_path with “/”)
		106	MUST	5.2	for absolute Request-URI’s ignore any host header field in the request
		107	MUST	5.2	for non-absolute Request-URI’s with a host header use the host head field value
		108	MUST	5.2	for non-absolute Request-URI’s with no host header return 400
		109	MUST NOT	5.2	generate responses with CR or LF except at the end of the status line
		110	MUST	6.1	understand the class of status codes (the 1st digit) and treat unrecognized responses as x00.
		111	MUST NOT	6.1	cache responses with unrecognized status codes
		112	MAY	7	transmit an entity if not otherwise restricted by the request method or response code
		113	MUST	7.1	in transparent mode: forward unrecognized header fields
		114	SHOULD	7.2.1	include a Content-Type header for generated HTTP/1.1 messages w/entity bodies
		115	SHOULD	7.2.1	treat unknown media-types as application/octet-stream
		116	SHOULD	8.1.1	implement HTTP/1.1 persistent connections
		117	SHOULD	8.1.2	assume http/1.1 servers will maintain persistent connections even after error responses from the server
		118	MUST NOT	8.1.2	send more requests on a connection after a close is signaled
		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
		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
		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)?
		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
		123	SHOULD NOT	8.1.2.1	assume a persistent connection is maintained for pre-HTTP/1.1 versions unless it is explicitly signaled.
		124	MUST	8.1.2.1	always create messages with self-defined message lengths
		125	MAY	8.1.2.2	pipeline requests to upstream servers
		126	MUST	8.1.2.2	send responses to pipelined requests in the order that the requests were received
		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
		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
		129	MUST	8.1.2.2	be prepared to resend requests if a server closes the connection before sending all the pipelined requests
		130	SHOULD NOT	8.1.2.2	pipeline non idempotent methods or non-idempotent sequences of methods.
		131	SHOULD	8.1.2.2	wait to send non-idempotent requests after receiving the response status for the previous request	note: this may be a non-issue for us.
		132	recommendation	8.1.3	implement the Connection header field properly
		133	MUST	8.1.3	signal persistent connections separately with clients and upstream servers
		134	MUST NOT	8.1.3	establish a HTTP/1.1 persistent connection with a HTTP/1.0 client
		135	SHOULD	8.1.4	issue a graceful close on the transport connection when timing out persistent connections
		136	SHOULD	8.1.4	watch persistent connections for close signals and respond to it as appropriate
		137	MAY	8.1.4	close any connection at any time.
		138	MUST	8.1.4	be able to recover from asynchronous close events.
		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
		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
		141	SHOULD	8.1.4	always respond to at least one request per connection if possible
		142	SHOULD NOT	8.1.4	close a connection in the middle of transmitting a response, unless network or client failure is suspected
		143	SHOULD	8.1.4	for the client program - limit the number of simultaneous connections maintained to a given server.
		144	SHOULD NOT	8.1.4	for the client program - maintain more than 2 connections with any given server or proxy
		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
		146	SHOULD	8.2.1	maintain persistent connections and use TCP flow control to resolve link congestion rather than terminating connections abruptly
		147	SHOULD	8.2.2	when sending message-bodies monitor the net connection for error’s.
		148	SHOULD	8.2.2	when sending message-bodies and a net error is detected immediately cease transmitting the body.
		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
		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
		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
		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
		153	SHOULD NOT	8.2.3	for the client program - if waiting for 100 before sending the request body, do not wait for an indefinite period before sending the request body
		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
		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.
		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
		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)
		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
		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
		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.
		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
		162	MAY	8.2.3	for the squid ‘server’ - omit a 100 continue status if some or all of the request body has already been received
		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
		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
		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
		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
		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
		168	SHOULD	8.2.3	cache the http version of recently access next hop servers
		169	MUST NOT	8.2.3	forward a 100 response 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
		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”	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” “ with a binary exponential backoff algorithm
		172	SHOULD NOT	8.2.4	continue retrying requests as per rfc 8.2.4 when an error status is received
		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)
		174	MUST	9	send the Host request-header field with ALL HTTP/1.1 requests
		175	SHOULD NOT	9.1.1	use GET and HEAD methods for anything other than retrieval (no side effects by squid)
		176	SHOULD NOT	9.1.2	have side effects caused when receiving requests to squid with OPTIONS or TRACE as the method
		177	MUST NOT	9.2	cache the results from an OPTIONS request
		178	MUST	9.2	for the client program - include a content type field when sending an OPTIONS request with an entity body
		179	MAY	9.2	for the squid ‘server’ - discard the request body from OPTIONS requests
		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)
		181	SHOULD	9.2	200 responses to the method OPTIONS with a message body should include information about the communications options
		182	MAY	9.2	use content-negotiation to select the format for information about the message body in 200 responses to the method OPTIONS
		183	MUST	9.2	include a Content-length header value of 0 or a response body in 200 responses to the method OPTIONS
		184	MAY	9.2	for the client program - use the Max-Forwards request-header to target a specific proxy in the request chain.
		185	MUST	9.2	check for a Max-Forwards field when squid receives an OPTIONS request on an absoluteURI for which request forwarding is permitted
		186	MUST NOT	9.2	forward a request with a Max-Forwards field when squid receives an OPTIONS request on an absoluteURI for which request forwarding is permitted and the value of Max-Forwards is 0.
		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.
		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.
		189	MUST NOT	9.2	add a Max-Forwards header to an OPTIONS request if non is present when squid recieves it
		190	MUST NOT	9.3	cache a GET response if it does not meet the HTTP caching requirements from rfc 2616 section 13
		191	MUST NOT	9.4	for the squid ‘server’ - generate a message-body in HEAD responses
		192	SHOULD	9.4	for the squid ‘server’ - generate identical http headers for a HEAD request to the equivalent GET request.
		193	MAY	9.4	update previously cached entities with the headers from a HEAD requests’ response
		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)
		195	MUST	9.5	follow the section 8.2 message transmission requirements for POST requests
		196	MUST NOT	9.5	cache POST responses unless they include appropriate cache-control or Expires headers
		197	SHOULD	9.6	for the squid ‘server’ - handling PUT requests - I skipped these as the cachmgr interface has not file storage capability
		198	SHOULD	9.6	treat any cached entities that match the Request URI of a PUT request as stale
		199	MUST	9.6	follow the section 8.2 message transmission requirements for PUT requests
		200	MUST NOT	9.6	cache responses to PUT Method requests
		201	SHOULD	9.7	for the squid ‘server’ - handling DELETE requests - I skipped these as the cachmgr interface has not file storage capability	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
		203	MUST NOT	9.7	cache responses to DELETE Method requests
		204	MUST NOT	9.8	for the squid client - create TRACE requests with an entity
		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
		206	MUST NOT	9.8	cache responses to TRACE Method requests
		207	MUST NOT	10.1	for the squid ‘server’ - send 1xx response codes to < HTTP/1.1 clients
		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
		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
		210	SHOULD	10.1.1	for the client when getting a 100-continue responses should continue with the request or ignore if the request has been completed.
		211	MUST	10.1.1	for the squid ‘server’ - send a final response after handling the request
		212	SHOULD	10.1.2	only upgrade protocols when it is advantageous to do so.
		213	MUST	10.2.2	for the squid ‘server’ - handling PUT requests - I skipped these as the cachmgr interface has not file storage capability
		214	MUST	10.2.5	terminate 204 responses by the first empty line after the header field
		215	MUST NOT	10.2.6	include entities in 205 responses
		216	MUST NOT	10.2.7	combine 206 responses with older content for the same entity unless the Etag or Last-Modified headers match exactly
		217	MUST NOT	10.2.7	cache 206 responses unless we support Range and Content-Range headers
		218	MUST	10.2.7	include the following headers in 206 responses 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
		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
		220	SHOULD	10.3.2	cache 301 responses unless otherwise indicated
		221	MUST NOT	10.3.2	cache 301 responses to requests other than GET or HEAD
		222	MUST NOT	10.3.3	cache 302 responses unless indicated by a Cache-Control or Expires header
		223	MUST NOT	10.3.3	cache 302 responses to requests other than GET or HEAD
		224	MUST NOT	10.3.4	cache 303 responses
		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
		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
		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
		228	MUST	10.3.6	when a 305 response is received, repeat that single request via the proxy in ‘Location’	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’
		230	MUST NOT	10.3.7	use the 306 status code
		231	SHOULD NOT	10.4.1	retry requests where 400 was returned unless the client retries
		232	SHOULD NOT	10.4.4	retry requests where 403 was returned
		233	MUST	10.4.6	include an Allow header listing valid methods for requests where squid creates a 405 method to the client
		234	MUST	10.4.8	return a Proxy-Authenticate header containing a challenge applicable to squid for the requested resource.
		235	MAY	10.4.9	retry 408 requests
		236	SHOULD NOT	10.4.10	retry 409 responses automatically
		237	SHOULD	10.4.11	cache 410 responses	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
		240	MAY	10.4.14	return a 413 error when the request entity is too large.
		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
		242	SHOULD	10.4.18	return 417 when we have unambiguous evidence that the expectation given in a request can not be met by the next hop server
		243	SHOULD	10.5	include an entity body when we create 5xx error responses explaining the issue (other than to HEAD requests)
		244	SHOULD	10.5.2	return a 501 if we don’t implement a given method and can’t just proxy it an hope
		245	SHOULD	10.5.3	return a 502 if we get an invalid upstream response
		246	SHOULD	10.5.4	return a 503 if we are overloaded, or unable to serve requests due to maintenance.
		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
		248	SHOULD	10.5.5	return a 504 on an upstream timeout, or timeout on an auxilary server - ie DNS/authentication helper	we may be returning 400 or 500 presently
	3.1	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
		250	OPTIONAL	11	implement basic and or digest authentication
		251	MAY	12	use content-negotiation on any entity body request/response - ie in selecting what language the error should be in
		252	MAY	12.1	for the squid client - include request header fields (Accept, Accept-Language, Accept-Encoding etc) in requests
		253	MAY	12.3	develop transparent negotiation capabilities within HTTP/1.1
		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.
		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
2.7		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).
		257	SHOULD	13.1.1	forward received responses even if the response itself is stale without adding a new Warning header
		258	SHOULD NOT	13.1.1	attempt to revalidate responses that become stale in transit to squid
		259	SHOULD	13.1.1	respond as per the 13.1.1 respond rules even if the origin server cannot be contacted.
		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
		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
		262	MUST	13.1.2	delete 1xx warnings from cached responses after successful revalidation
		263	MAY	13.1.2	generate 1xx warnings when validating a cached entry
		264	MUST NOT	13.1.2	delete 2xx warning from cached responses after successful revalidation
		265	MAY	13.1.2	choose the warning text description language (perhaps based on Accept headers)
		266	MAY	13.1.2	allow/create responses with multiple warnings, including multiple warnings with the same code
		267	recommendation	13.1.3	use the most restrictive interpretation of caching issue /spec conflicts
		268	MAY	13.1.5	have squid configurable to return stale responses even when not requested by clients
		269	MUST	13.1.5	mark stale responses with a Warning header
		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	ie: offline mode, refresh to IMS are allowed but MUST require deliberate configuration by the admin
N/A	N/A	271	SHOULD	13.2.3	be running on a host that uses NTP or equivalent for clock synchronization
		272	MUST	13.2.3	calculate corrected_received_age as max(now-date_value, age_value)
		273	MUST	13.2.3	interpret Age header values (age_value) relative to the time the request was initiated, not the response time.
		274	MUST	13.2.3	calculate corrected_initial_age as corrected_received_age +(now - request_time) ; request_time = time the request was sent upstream
		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)
		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
		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
		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
		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.	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	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
		282	MUST	13.3.3	consider two validators strongly equal IFF both validators are identical, and both are NOT weak
		283	MUST	13.3.3	consider two validators weakly equal IFF both validators are identical, and one or both are NOT strong
		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
		285	MUST	13.3.3	when receiving conditional requests the use strong comparison (no weak compares allowed)
		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
		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
		288	MUST NOT	13.3.5	use other headers than entity tags and Last-Modified for validation
		289	MAY	13.4	always cache a successful response (unless constrained by 14.9)
		290	MAY	13.4	return cached responses without validation while fresh (unless constrained by 14.9)
		291	MAY	13.4	return cached responses after succesful validation (unless constrained by 14.9)
		292	MAY	13.4	cache responses with no validator or expiration time, but shouldn’t do so in normal conditions
		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)
		294	MUST NOT	13.4	return responses to status codes other than (200, 203, 206, 300, 301 or 410) in a reply to subsequent 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
		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
		296	MUST	13.5.1	transmit cached end to end headers in any response formed from that cache entry
		297	MUST	13.5.1	list newly defined hop to hop headers under the connection header
		298	SHOULD NOT	13.5.2	modify end to end headers unless the definition of that header specifically allows or requires its modification
		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
		300	MAY	13.5.2	as a transparent proxy; add an Expires header if not already present in a response, and MUST give it the same value as the Date header of that response
		301	MUST NOT	13.5.2	as a transparent proxy; add (Content-Location; Content-MD5;- Etag; Last-Modified) headers in a request or response
		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”
		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”
		304	MUST	13.5.2	as a transparent proxy; preserve the entity-length of the entity body in a response/request
		305	MAY	13.5.2	as a transparent proxy; change the preserve the transfer-length in a response/request
		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
		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
		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
		309	MAY	13.5.4	combine byte ranges if both the incoming response and the cache entry have validators, and the validators match using the strong comparison
		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
		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
		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
		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
		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
		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
		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
		317	MAY	13.8	store incomplete responses
		318	MUST	13.8	treat incomplete responses as partial responses
		319	MUST NOT	13.8	return a partial response to a client without marking it as such (using 206 status code)
		320	MUST NOT	13.8	return a partial response to a client with status 200
		321	MAY	13.8	forward 5xx responses received while revalidating entries to the client, or act as if the server failed to respond
		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
		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 response
		324	SHOULD NOT	13.9	cache GET and HEAD responses from HTTP/1.0 servers with ? In the URI path
		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
		326	SHOULD	13.10	invalidate entities referred to by the Request-URI in non understood methods if we pass them upstream
		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)
		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 response from the server arrives.
		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 response from the server arrives.
		330	SHOULD	13.12	when a new response to an existing cached resource arrives, use the new response to reply to the current request
		331	MAY	13.12	when a new response to an existing cached resource arrives, update the cache with the new response
		332	MAY	13.12	when a new response to an existing cached resource arrives, use it to respond to future requests as appropriate
		333	MAY	14.1	include parameters for media types that support them
		334	MAY	14.1	include accept-params for media types. (q=0 to q=1) (see 3.9)
		335	SHOULD	14.1	for the squid ‘server’ send 406 if we cannot get an acceptable media type for the client request
		336	MAY	14.2	have q values for charsets
		337	SHOULD	14.2	for the squid ‘server’ send 406 if we cannot get an acceptable charset for the client request
		338	MAY	14.3	have q values for content-coding
		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
		340	MAY	14.3	assume the client will accept any content coding when no Accept-Encoding header is presented
		341	SHOULD	14.3	for the squid ‘server’ send identity content-coding when no Accept-Encoding header is presented
N/A	N/A	342	MAY	14.4	have q values for preferred language
		343	SHOULD	14.4	assume all languages are ok when there is no header
		344	MAY	14.5	for the squid ‘server’ send Accept-ranges: none to tell clients not to attempt range requests
		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).
		346	SHOULD	14.6	use integers of at least 31 bits
		347	MUST	14.7	present an Allow header in 405 responses
		348	MUST NOT	14.7	modify the allow header
		349	SHOULD	14.8	have a set of credentials valid for an entire realm (including all sub-resources) (ie for web-accel operation)
		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
		351	MUST	14.8	always revalidate responses with cache-control: s-maxage=0
		352	MUST	14.9	follow the cache-control header directives at all times
		353	MUST	14.9	pass cache-control directives through to the next link in the message path (ie don’t eat them)
		354	MAY	14.9.1	cache responses with cache-control: public even of the header/method might not normally be cacheable
		355	MUST NOT	14.9.1	cache responses with cache-control: private
		356	MUST NOT	14.9.1	use responses with cache-control: no-cache to satisfy other requests without successful revalidation	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
		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
		359	MAY	14.9.2	use no-store on requests or responses to prevent data storage
		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	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	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
		363	MUST	14.9.3	mark stale responses with Warning 110
		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
		365	MUST NOT	14.9.4	use a cached copy to respond to a request with cache-control: no-cache or Pragma: no-cache
		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
		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
		368	MUST	14.9.4	obey the must-revalidate directive at all times
		369	MUST	14.9.4	return 504 if a must-revalidate directive would need access to an unavailable origin server
		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
		371	MUST	14.9.6	ignore unrecognized cache-control headers
		372	MUST	14.10	parse the Connection header before a message is forwarded
		373	MUST	14.10	remove headers from messages that match headers specified in the connection header
		374	MUST NOT	14.10	list end to end headers in the connection header
		375	MUST	14.10	for applications that do not support persistent connection (ie squid ‘server’ and client) include Connection: close in every message
		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
		377	MAY	14.11	as a NON-TRANSPARENT proxy modify content-coding to be more suitable to a client request
		378	MUST	14.11	if the content encoding of an entity is not “identity”
		379	MUST	14.11	list in applied order the content codings applied to an entity
N/A	N/A	380	MAY	14.12	list multiple languages in a Content-Language header if the response is intended for multiple audiences (perhaps a multi-lingual error page?)	only one language sent
		381	SHOULD	14.13	use and send the Content-Length header unless prohibited by section 4.4
		382	MUST NOT	14.15	generate Content-MD5 headers
		383	MAY	14.15	check Content-MD5 headers
		384	MUST	14.15	remove transfer-encodings before checking the MD5
		385	MUST NOT	14.15	convert line breaks to CRLF before checking the MD5
		386	SHOULD	14.16	indicate the total length of the full entity body in Content-Range headers
		387	MUST	14.16	only specify one range in byte-range-resp-spec
		388	MUST	14.16	use absolute byte positions for byte-range-resp-spec values
		389	MUST	14.16	ignore invalid byte-range-resp-spec and any content transferred with it
		390	MUST NOT	14.16	have response code 206 with a byte-range-resp-spec of *
		391	MUST	14.18	assign a Date header if we receive a message without one,
		392	SHOULD	14.18	assign the best available approximation of the date and time of message generation when we assign Date headers
		393	MAY	14.19	use Entity tags for comparison with other entities from the same resource
		394	MUST	14.21	treat invalid Expires headers (NON RFC 1123 format) as being in the past
		395	MAY	14.22	log the From header
		396	SHOULD NOT	14.22	use the From header for access-control
		397	MUST	14.23	for clients: include a Host header in all http/1.1 requests
		398	MUST	14.23	for clients: include an empty Host header in all http/1.1 requests when no host name is available
		399	MUST	14.23	ensure that all requests forwarded include an appropriate Host header
		400	MUST	14.23	respond with 400 to http/1.1 requests missing a Host header
		401	MUST	14.24	use the strong comparison when comparing entity tags for If-Match
		402	SHOULD	14.25	return a 304 to IMS requests that have not been modified (using cached data if possible)
		403	MUST	14.31	check and decrement (if greater than 0) the Max-Forwards header if present in TRACE and OPTIONS requests
		404	MUST	14.31	respond as the final recipient if the Max-Forwards header is 0 on a TRACE or OPTIONS request
		405	MAY	14.31	ignore the Max-Forwards header for all other methods covered by rfc 2616
		406	SHOULD	14.32	forward requests with Pragme: no-cache upstream even if a cached copy exists
		407	MUST	14.32	pass Pragma directives up/downstream in all cases
		408	SHOULD	14.32	ignore pragma directives not relevant or understood by us
		409	SHOULD	14.32	treat pragme: no-cache as cache-control: no-cache
		410	MUST	14.33	include Proxy-Authenticate when sending a 407 response	note: NTLM auth requires an unrecommended order
		411	SHOULD NOT	14.33	pass Proxy-Authenticate downstream
		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)
		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
		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
		415	MUST	14.35.1	ignore a header field with an invalid byte-range-spec
		416	SHOULD	14.35.1	return 416 if a byte-range-set is unsatisfiable
		417	SHOULD	14.35.1	return 206 when returning ranges
		418	MAY	14.35.2	for the client - request one or more subranges on conditional or un-conditional GET requests
		419	MAY	14.35.2	ignore the range header.	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
		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
		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
		423	MAY	14.37	use Retry-After to indicate how long a client should wait before requesting the new location
		424	MUST NOT	14.38	modify the Server header on forwarded responses
		425	SHOULD	14.38	include a Via header on forwarded responses	unless admin suppressed
		426	MUST	14.39	include the TE connection token whenever we use TE on a connection
		427	SHOULD NOT	14.40	include header fields in the trailer with having sent a Trailer header
		428	MUST NOT	14.40	send Transfer-Encoding; Content-Length or Trailer as Trailer field values
		429	MUST	14.41	list in the order applied the transfer-encodings applied to a response (ie rsync, gzip
		430	MUST	14.42	use the upgrade header in a response with status code 101
		431	MUST	14.42	include the Upgrade connection-token whenever we use the Upgrade header
		432	SHOULD	14.43	for the client - include a user-Agent field in requests
		433	SHOULD	14.44	include a Vary header on any cacheable response we generate that used server negotiation
		434	MAY	14.44	for the ‘server’ include a vary header with a non-cacheable response the used server negotiation
		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
		436	MUST NOT	14.44	generate a * value for a vary field
		437	MUST	14.45	fill in the Via header
		438	MAY	14.45	replace the host in the via header with a pseudonym for security/privacy
		439	MUST	14.45	append our details to the Via header
		440	MAY	14.45	remove comments from the via header before forwarding
		441	MAY	14.45	put comments in the via header before forwarding
		442	SHOULD NOT	14.45	when used as a gateway/ http firewall forward names/hosts/ports of hosts within the firewall	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	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
		445	MAY	14.45	for organizations with privacy concerns: collapse multiple protocol-value entries into one entry in the via header
		446	SHOULD NOT	14.45	combine multiple entries unless they are all under the same organizations control and the hosts have already been pseudonymized
		447	MUST NOT	14.45	combine multiple entries in the via header with different protocol values
		448	MAY	14.46	have responses with more than 1 warning header
		449	SHOULD	14.46	generate warn-text in the natural language most likely to be intelligible to the user receiving the response
		450	MAY	14.46	decide on the language for warnings using ANY available knowledge
		451	MUST	14.46	if sending a warning in a charset other than ISO-8859-1 encode it as per rfc 2047
		452	SHOULD	14.46	add new warning headers after existing warning headers
		453	MUST NOT	14.46	delete a warning it receives with a given message
		454	SHOULD	14.46	remove any warning headers associated with a cached response after successful validation (except as specified for some warning codes)
		455	MUST	14.46	add any warning headers received in validation responses to cached responses
		456	MUST	14.46	generate warning 110 on stale responses
		457	MUST	14.46	generate warning 111 on stale responses sent when revalidation failed
		458	SHOULD	14.46	generate warning 112 if we are offline intentionally for any length of time
		459	MUST	14.46	generate warning 113 if our heuristic chose a freshness lifetime > 24 hours and the response’s age is >24 hours
		460	MAY	14.46	include and arbitrary info we want logged or presented to the user in a Warning 199
		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
		462	MAY	14.46	include and arbitrary info we want logged or presented to the user in a Warning 299
		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
		464	MUST	14.46	delete warning-values that have a warn-date differing form the Date value in the response
		465	MUST	14.46	delete the warning header if it is empty
		466	MUST	14.47	include WWW-Authenticate in 401 responses
		467	SHOULD	15.1	be careful not to disclose personal information of the clients
		468	SHOULD	15.1.2	be able to filter/alter the From field when acting as a gateway
		469	SHOULD	19.3	assume RC 850 dates more than 50 years in the future are in the past
		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
		471	MUST	19.3	do date calculations in GMT
		472	MUST	19.3	convert HTTP header dates to GMT using the most conservative possible conversion if they are not in GMT
		473	idea	19.5.1	sanitize the content-disposition header by removing directory information

Categories: WantedFeature,Feature

Navigation: Site Search, Site Pages, Categories, 🔼 go up