NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! When responding to any of the issue items listed in this document, please: (1) confine your message to ONE item only, unless several items are inextricably linked. (2) include the relevant MMS_AUDIT_ITEM_xxx code in the Subject of your message. NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! NOTE! The following (rather lengthy) list of proposed changes to draft-ietf-http-v11-spec-rev-03.txt is the result of an audit for correct use of the "requirements keywords" described in RFC 2119. These keywords include "MUST", "MUST NOT", "REQUIRED", "SHOULD", SHOULD NOT", "MAY", and "OPTIONAL", as well as several keywords that are not actually used in draft-ietf-http-v11-spec-rev-03. The intent of this audit is NOT to change the intended meaning of the requirements imposed by the HTTP/1.1 specification. Rather, it is to make sure that all normative requirements are correctly distinguished using one of the "requirements keywords", that these keywords are not used when the intented meaning is not normative, and that there are no obvious contradictions in the text related to their use. In some cases, it is not entirely clear whether a statement is really intended to be normative, or if it is intended to be descriptive or explanatory. We have used our best judgement. Secondarily, we have tried to rewrite certain uses of lower-case forms of these keywords ("must", "should", and "may") to use other language, so as to avoid potential confusion. For example, the word "may" is often more accurately replaced by the word "might". However, we have not addressed every use of these lower-case words, especially when they occur in clearly explanatory text. The format of this report is based on a "context diff", as produced by the UNIX "diff -c" program, between the original ASCII form of draft-ietf-http-v11-spec-rev-03.txt and an editted form. Each block of "diff -c" output is assigned a distinct issue tag, of the form MMS_AUDIT_ITEM_xxx, and is followed by a "Reason" for the change. When an item contains two or more changes (because they fall close together in the text), they are identified by separately numbered explanations under "Reason." *************** ** issue MMS_AUDIT_ITEM_001: *** 579,585 **** An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible ! translation, to other servers. A proxy must implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non- --- 579,585 ---- An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible ! translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non- *************** Reason: This is apparently a normative MUST. --------------- ** issue MMS_AUDIT_ITEM_002: *** 830,836 **** A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "#element " indicating at least and at most elements, each separated by one or more commas (",") ! and optional linear white space (LWS). This makes the usual form of lists very easy; a rule such as "( *LWS element *( *LWS "," *LWS element )) " can be shown as "1#element". Wherever this construct is used, null elements are --- 830,836 ---- A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "#element " indicating at least and at most elements, each separated by one or more commas (",") ! and OPTIONAL linear white space (LWS). This makes the usual form of lists very easy; a rule such as "( *LWS element *( *LWS "," *LWS element )) " can be shown as "1#element". Wherever this construct is used, null elements are *************** Reason: OPTIONAL is a keyword as used here. --------------- ** issue MMS_AUDIT_ITEM_003: *** 837,843 **** allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least ! one non-null element must be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two. --- 837,843 ---- allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least ! one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two. *************** Reason: This is apparently a normative MUST. --------------- ** issue MMS_AUDIT_ITEM_004: *** 857,863 **** INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998 ! of a field. At least one delimiter (LWS and/or separators[jg7]) must exist between any two tokens (for the definition of "token" above), since they would otherwise be interpreted as a single token. --- 857,863 ---- INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998 ! of a field. At least one delimiter (LWS and/or separators[jg7]) MUST exist between any two tokens (for the definition of "token" above), since they would otherwise be interpreted as a single token. *************** Reason: This is apparently a normative MUST. --------------- ** issue MMS_AUDIT_ITEM_005: *** 894,900 **** LWS = [CRLF] 1*( SP | HT ) The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of ! *TEXT may contain characters from character sets other than ISO 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. TEXT = *(qdtext | quoted-pair ) <"> ) qdtext = > ! The backslash character ("\") may be used as a single-character quoting mechanism only within quoted-string and comment constructs. quoted-pair = "\" CHAR --- 930,936 ---- quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) qdtext = > ! The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. quoted-pair = "\" CHAR *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_007: *** 942,948 **** a quoted-string". ! This is strange, and CRLF's should be allowed, but backward compatibility constraints mean that they are not allowed in general. --- 942,948 ---- a quoted-string". ! This is strange, and CRLF's ought to be allowed, but backward compatibility constraints mean that they are not allowed in general. *************** Reason: This "should" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_008: *** 972,978 **** HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT Note that the major and minor numbers MUST be treated as separate ! integers and that each may be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower Fielding, et al [Page 16] --- 972,978 ---- HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT Note that the major and minor numbers MUST be treated as separate ! integers and that each MAY be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower Fielding, et al [Page 16] *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_009: *** 990,996 **** The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant. ! Proxy and gateway applications must be careful when forwarding messages in protocol versions different from that of the application. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway MUST NOT send a message with a version indicator which is --- 990,996 ---- The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant. ! Proxy and gateway applications need to be careful when forwarding messages in protocol versions different from that of the application. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway MUST NOT send a message with a version indicator which is *************** Reason: This "must" is not intended to be normative. (One can't combine a normative MUST with a vague requirement such as "be careful".) --------------- ** issue MMS_AUDIT_ITEM_010: *** 1043,1051 **** 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). ! Note: Servers should be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations ! may not properly support these lengths. 3.2.2 http URL --- 1043,1051 ---- 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). ! Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations ! might not properly support these lengths. 3.2.2 http URL *************** Reason: This "should" is not phrased as a normative requirement. --------------- ** issue MMS_AUDIT_ITEM_011: *** 1059,1065 **** If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the ! resource is abs_path. The use of IP addresses in URL's should be avoided whenever possible (see RFC 1900 [24]). If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2). If a proxy receives a host name which is not a --- 1059,1065 ---- If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the ! resource is abs_path. The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2). If a proxy receives a host name which is not a *************** Reason: This is apparently a normative SHOULD. (also, note that "URLs" is correct here, not the possessive form "URL's"). --------------- ** issue MMS_AUDIT_ITEM_012: *** 1123,1129 **** to UTC (Coordinated Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for time zone, and MUST be assumed when reading the asctime format. HTTP- ! date is case sensitive and does not allow additional LWS beyond that specifically included as SP in the grammar. HTTP-date = rfc1123-date | rfc850-date | asctime-date --- 1123,1129 ---- to UTC (Coordinated Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for time zone, and MUST be assumed when reading the asctime format. HTTP- ! date is case sensitive and MUST NOT include additional LWS beyond that specifically included as SP in the grammar. HTTP-date = rfc1123-date | rfc850-date | asctime-date *************** Reason: This is clearly meant to be normative. --------------- ** issue MMS_AUDIT_ITEM_013: *** 1254,1263 **** coding (LZW). Note: Use of program names for the identification of encoding ! formats is not desirable and should be discouraged for future encodings. Their use here is representative of historical practice, not good design. For compatibility with previous implementations of ! HTTP, applications should consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. deflate --- 1254,1263 ---- coding (LZW). Note: Use of program names for the identification of encoding ! formats is not desirable and is discouraged for future encodings. Their use here is representative of historical practice, not good design. For compatibility with previous implementations of ! HTTP, applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. deflate *************** Reason: This is apparently a normative SHOULD. (Since it appears in a "Note", it's not entirely clear whether it's normative or not.) --------------- ** issue MMS_AUDIT_ITEM_014: *** 1269,1277 **** whatsoever. This content-coding is used only in the Accept-Encoding header, and SHOULD NOT be used in the Content-Encoding header. ! New content-coding value tokens should be registered; to allow interoperability between clients and servers, specifications of the ! content coding algorithms needed to implement a new value should be publicly available and adequate for independent implementation, and conform to the purpose of content coding defined in this section. --- 1269,1277 ---- whatsoever. This content-coding is used only in the Accept-Encoding header, and SHOULD NOT be used in the Content-Encoding header. ! New content-coding value tokens SHOULD be registered; to allow interoperability between clients and servers, specifications of the ! content coding algorithms needed to implement a new value SHOULD be publicly available and adequate for independent implementation, and conform to the purpose of content coding defined in this section. *************** Reason: (1) This is apparently a normative SHOULD. (2) This is apparently a normative SHOULD. --------------- ** issue MMS_AUDIT_ITEM_015: *** 1294,1300 **** transfer-coding = "chunked" | transfer-extension transfer-extension = token *( ";" parameter ) ! Parameters may be in the form of attribute/value pairs. parameter = attribute "=" value attribute = token --- 1294,1300 ---- transfer-coding = "chunked" | transfer-extension transfer-extension = token *( ";" parameter ) ! Parameters are in the form of attribute/value pairs. parameter = attribute "=" value attribute = token *************** Reason: This "may" is not intended to be normative. (It's a description of the BNF, not a optional form.) --------------- ** issue MMS_AUDIT_ITEM_016: *** 1325,1331 **** "gzip" (section 3.4.1), "compress" (section 3.4.1), and "deflate" (section 3.4.1). ! New transfer-coding value tokens should be registered in the same way as new content-coding value tokens (section 3.4.1). A server which receives an entity-body with a transfer-coding it does --- 1325,1331 ---- "gzip" (section 3.4.1), "compress" (section 3.4.1), and "deflate" (section 3.4.1). ! New transfer-coding value tokens SHOULD be registered in the same way as new content-coding value tokens (section 3.4.1). A server which receives an entity-body with a transfer-coding it does *************** Reason: This is apparently a normative SHOULD. (Although perhaps it applies to specification-writers, not to implementors?) --------------- ** issue MMS_AUDIT_ITEM_017: *** 1338,1344 **** The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator, followed by ! an optional trailer containing entity-header fields. This allows dynamically-produced content to be transferred along with the Fielding, et al [Page 22] --- 1338,1344 ---- The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator, followed by ! an OPTIONAL trailer containing entity-header fields. This allows dynamically-produced content to be transferred along with the Fielding, et al [Page 22] *************** Reason: OPTIONAL is a keyword as used here. --------------- ** issue MMS_AUDIT_ITEM_018: *** 1408,1427 **** type = token subtype = token ! Parameters may follow the type/subtype in the form of attribute/value pairs (as defined in section 3.6). The type, subtype, and parameter attribute names are case-insensitive. ! Parameter values may or may not be case-sensitive, depending on the semantics of the parameter name. Linear white space (LWS) MUST NOT be used between the type and subtype, nor between an attribute and its ! value. The presence or absence of a parameter may be significant to the processing of a media-type, depending on its definition within the media type registry. Note: some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications, ! implementations should only use media type parameters when they are required by that type/subtype definition. Media-type values are registered with the Internet Assigned Number --- 1408,1427 ---- type = token subtype = token ! Parameters MAY follow the type/subtype in the form of attribute/value pairs (as defined in section 3.6). The type, subtype, and parameter attribute names are case-insensitive. ! Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. Linear white space (LWS) MUST NOT be used between the type and subtype, nor between an attribute and its ! value. The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry. Note: some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications, ! implementations SHOULD only use media type parameters when they are required by that type/subtype definition. Media-type values are registered with the Internet Assigned Number *************** Reason: (1) This is apparently a normative MAY. (2) These two "mays" are not intended to be normative. (3) This "may" is not intended to be normative. (4) This is apparently a normative SHOULD, although it appears in a "Note." --------------- ** issue MMS_AUDIT_ITEM_019: *** 1519,1527 **** User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Server: Apache/0.8.4 ! Product tokens should be short and to the point -- use of them for ! advertising or other non-essential information is explicitly forbidden. ! Although any token character may appear in a product-version, this token SHOULD only be used for a version identifier (i.e., successive versions Fielding, et al [Page 25] --- 1519,1527 ---- User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Server: Apache/0.8.4 ! Product tokens SHOULD be short and to the point. They MUST NOT ! be used for advertising or other non-essential information. ! Although any token character MAY appear in a product-version, this token SHOULD only be used for a version identifier (i.e., successive versions Fielding, et al [Page 25] *************** Reason: (1) This is apparently a normative SHOULD. (2) This is a normative MUST NOT, but wasn't expressed as such. (3) This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_020: *** 1595,1610 **** entity-tag = [ weak ] opaque-tag weak = "W/" opaque-tag = quoted-string ! A "strong entity tag" may be shared by two entities of a resource only if they are equivalent by octet equality. ! A "weak entity tag," indicated by the "W/" prefix, may be shared by two entities of a resource only if the entities are equivalent and could be substituted for each other with no significant change in semantics. A weak entity tag can only be used for weak comparison. An entity tag MUST be unique across all versions of all entities ! associated with a particular resource. A given entity tag value may be used for entities obtained by requests on different URIs without implying anything about the equivalence of those entities. --- 1595,1610 ---- entity-tag = [ weak ] opaque-tag weak = "W/" opaque-tag = quoted-string ! A "strong entity tag" MAY be shared by two entities of a resource only if they are equivalent by octet equality. ! A "weak entity tag," indicated by the "W/" prefix, MAY be shared by two entities of a resource only if the entities are equivalent and could be substituted for each other with no significant change in semantics. A weak entity tag can only be used for weak comparison. An entity tag MUST be unique across all versions of all entities ! associated with a particular resource. A given entity tag value MAY be used for entities obtained by requests on different URIs without implying anything about the equivalence of those entities. *************** Reason: (1) This is apparently a normative MAY. (2) This is apparently a normative MAY. (3) This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_021: *** 1614,1620 **** HTTP/1.1 allows a client to request that only part (a range of) the response entity be included within the response. HTTP/1.1 uses range units in the Range (section 14.35) and Content-Range (section 14.16) ! header fields. An entity may be broken down into subranges according to various structural units. range-unit = bytes-unit | other-range-unit --- 1614,1620 ---- HTTP/1.1 allows a client to request that only part (a range of) the response entity be included within the response. HTTP/1.1 uses range units in the Range (section 14.35) and Content-Range (section 14.16) ! header fields. An entity can be broken down into subranges according to various structural units. range-unit = bytes-unit | other-range-unit *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_022: *** 1621,1627 **** bytes-unit = "bytes" other-range-unit = token The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 ! implementations may ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges. --- 1621,1627 ---- bytes-unit = "bytes" other-range-unit = token The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 ! implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges. *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_023: *** 1640,1646 **** the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header ! fields, and an optional message-body. generic-message = start-line *message-header --- 1640,1646 ---- the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header ! fields, and an OPTIONAL message-body. generic-message = start-line *message-header *************** Reason: OPTIONAL is a keyword as used here. --------------- ** issue MMS_AUDIT_ITEM_024: *** 1655,1665 **** In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and ! receives a CRLF first, it should ignore the CRLF. Note: certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly ! forbidden by the BNF, an HTTP/1.1 client must not preface or follow a request with an extra CRLF. --- 1655,1665 ---- In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and ! receives a CRLF first, it SHOULD ignore the CRLF. Note: certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly ! forbidden by the BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an extra CRLF. *************** Reason: (1) This is apparently a normative SHOULD. (2) This is apparently a normative MUST NOT (it appears in a "Note" but explicitly is restating a formal requirement). --------------- ** issue MMS_AUDIT_ITEM_025: *** 1670,1679 **** (section 7.1) fields, follow the same generic format as that given in Section 3.1 of RFC 822 [9]. Each header field consists of a name followed by a colon (":") and the field value. Field names are case- ! insensitive. The field value may be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT. ! Applications SHOULD follow "common form" when generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common forms. --- 1670,1680 ---- (section 7.1) fields, follow the same generic format as that given in Section 3.1 of RFC 822 [9]. Each header field consists of a name followed by a colon (":") and the field value. Field names are case- ! insensitive. The field value MAY be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT. ! Applications SHOULD follow "common form", where one is known or ! indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common forms. *************** Reason: (1) This is apparently a normative MAY. (2) The term "common form" isn't explicitly defined for the document as a whole, and it's not legitimate to associate a SHOULD-level requirement with an undefined term. Certain header field definitions and protocol parameters do have "common forms", and so when these are defined as such, it's appropriate to include a SHOULD-level requirement for them. --------------- ** issue MMS_AUDIT_ITEM_026: *** 1688,1694 **** header fields first, followed by request-header or response-header fields, and ending with the entity-header fields. ! Multiple message-header fields with the same field-name may be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header --- 1689,1695 ---- header fields first, followed by request-header or response-header fields, and ending with the entity-header fields. ! Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header *************** Reason: This is apparently a normative MAY. It's not clear why this paragraph is indented more than usual. --------------- ** issue MMS_AUDIT_ITEM_027: *** 1719,1726 **** Transfer-Encoding MUST be used to indicate any transfer codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding is a property of the message, not of the entity, and ! thus can be added or removed by any application along the ! request/response chain. The rules for when a message-body is allowed in a message differ for requests and responses. --- 1720,1728 ---- Transfer-Encoding MUST be used to indicate any transfer codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding is a property of the message, not of the entity, and ! thus MAY be added or removed by any application along the ! request/response chain. (However, section 3.6 places restrictions ! on when certain transfer-codings may be used.) The rules for when a message-body is allowed in a message differ for requests and responses. *************** Reason: This is apparently a normative MAY, but with qualifications that should be noted via the cross-reference. --------------- ** issue MMS_AUDIT_ITEM_028: *** 1740,1746 **** include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message- ! body. All other responses do include a message-body, although it may be of zero length. --- 1742,1748 ---- include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message- ! body. All other responses do include a message-body, although it MAY be of zero length. *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_029: *** 1882,1888 **** by the server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the server. The methods GET and HEAD MUST be supported by all general- ! purpose servers. All other methods are optional; however, if the above methods are implemented, they MUST be implemented with the same semantics as those specified in section 9. --- 1884,1890 ---- by the server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the server. The methods GET and HEAD MUST be supported by all general- ! purpose servers. All other methods are OPTIONAL; however, if the above methods are implemented, they MUST be implemented with the same semantics as those specified in section 9. *************** Reason: OPTIONAL is a keyword as used here. --------------- ** issue MMS_AUDIT_ITEM_030: *** 1907,1913 **** would be OPTIONS * HTTP/1.1 ! The absoluteURI form is required when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. Note that the proxy MAY forward the request on to another proxy or directly to the server specified by --- 1909,1915 ---- would be OPTIONS * HTTP/1.1 ! The absoluteURI form is REQUIRED when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. Note that the proxy MAY forward the request on to another proxy or directly to the server specified by *************** Reason: REQUIRED is a keyword as used here. --------------- ** issue MMS_AUDIT_ITEM_031: *** 1937,1943 **** given as "/" (the server root). The Request-URI is transmitted in the format specified in section 3.2.1. ! The origin server MUST decode the Request-URI in order to properly interpret the request. Servers SHOULD respond to invalid Request-URIs with an appropriate status code. --- 1939,1946 ---- given as "/" (the server root). The Request-URI is transmitted in the format specified in section 3.2.1. ! If the Request-URI is encoded using the "% HEX HEX" encoding [42], ! the origin server MUST decode the Request-URI in order to properly interpret the request. Servers SHOULD respond to invalid Request-URIs with an appropriate status code. *************** Reason: I had to puzzle over this statement (specifically, what "decode" means) for a long time. It turns out that in RFC2068, section 3.2.1 described the "% HEX HEX" encoding for URLs. In the current draft-ietf-http-v11-spec-rev-03.txt, however, the URL syntax is imported from another document, and the concept of URL-encoding is not explicit in 3.2.1. --------------- ** issue MMS_AUDIT_ITEM_032: *** 1961,1973 **** 5.2 The Resource Identified by a Request ! HTTP/1.1 origin servers SHOULD be aware that the exact resource ! identified by an Internet request is determined by examining both the ! Request-URI and the Host header field. An origin server that does not allow resources to differ by the ! requested host MAY ignore the Host header field value. (But see section ! 19.6.1.1 for other requirements on Host support in HTTP/1.1.) An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity hostnames) --- 1964,1977 ---- 5.2 The Resource Identified by a Request ! The exact resource identified by an HTTP/1.1 request is determined ! by both the Request-URI and the Host header field. An origin server that does not allow resources to differ by the ! requested host MAY ignore the Host header field value when ! determining the resource identified by an HTTP/1.1 request. ! (But see section 19.6.1.1 for other requirements on Host support ! in HTTP/1.1.) An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity hostnames) *************** Reason: (1) It is not legitimate to use a SHOULD-level requirement keyword with a vague concept such as "be aware". This first paragraph is really just a descriptive statement, not a normative one. (2) 19.6.1.1 does not actually allow an HTTP/1.1 server to entirely ignore the Host header in any HTTP/1.1 request, since it "MUST report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host request-header." The MAY here refers only to ignoring a Host header field when determining the resource identified by an HTTP/1.1 request. --------------- ** issue MMS_AUDIT_ITEM_033: *** 2084,2090 **** valid request The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's, are presented ! below. The reason phrases listed here are only recommended -- they may be replaced by local equivalents without affecting the protocol. Status-Code = "100" ; Continue --- 2088,2094 ---- valid request The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's, are presented ! below. The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol. Status-Code = "100" ; Continue *************** Reason: "recommended" is a keyword equivalent to SHOULD in RFC2119 terminology, so it's not really appropriate here. This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_034: *** 2188,2196 **** 7.1 Entity Header Fields ! Entity-header fields define optional metainformation about the entity- body or, if no body is present, about the resource identified by the ! request. entity-header = Allow ; Section 14.7 | Content-Encoding ; Section 14.11 --- 2192,2201 ---- 7.1 Entity Header Fields ! Entity-header fields define metainformation about the entity- body or, if no body is present, about the resource identified by the ! request. Some of this metainformation is OPTIONAL; some might be ! REQUIRED by portions of this specification. entity-header = Allow ; Section 14.7 | Content-Encoding ; Section 14.11 *************** Reason: Entity-header fields are not always "optional". For example, Content-Length is mandatory in many circumstances. --------------- ** issue MMS_AUDIT_ITEM_035: *** 2224,2230 **** entity-body = *OCTET An entity-body is only present in a message when a message-body is present, as described in section 4.3. The entity-body is obtained from ! the message-body by decoding any Transfer-Encoding that may have been applied to ensure safe and proper transfer of the message. --- 2229,2235 ---- entity-body = *OCTET An entity-body is only present in a message when a message-body is present, as described in section 4.3. The entity-body is obtained from ! the message-body by decoding any Transfer-Encoding that might have been applied to ensure safe and proper transfer of the message. *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_036: *** 2301,2307 **** A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP ! connection. That is, unless otherwise indicated, the client may assume that the server will maintain a persistent connection. Persistent connections provide a mechanism by which a client and a --- 2306,2312 ---- A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP ! connection. That is, unless otherwise indicated, the client can assume that the server will maintain a persistent connection. Persistent connections provide a mechanism by which a client and a *************** Reason: This "may" is not intended to be normative. (I think; this is a borderline call.) --------------- ** issue MMS_AUDIT_ITEM_037: *** 2339,2345 **** signaled. See section 19.6.2 for more information on backward compatibility with HTTP/1.0 clients. ! In order to remain persistent, all messages on the connection must have a self-defined message length (i.e., one not defined by closure of the connection), as described in section 4.4. --- 2344,2350 ---- signaled. See section 19.6.2 for more information on backward compatibility with HTTP/1.0 clients. ! In order to remain persistent, all messages on the connection MUST have a self-defined message length (i.e., one not defined by closure of the connection), as described in section 4.4. *************** Reason: This is apparently a normative MUST. --------------- ** issue MMS_AUDIT_ITEM_038: *** 2361,2367 **** Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a ! premature termination of the transport connection may lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request. --- 2366,2372 ---- Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a ! premature termination of the transport connection can lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request. *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_039: *** 2404,2410 **** network. A client, server, or proxy MAY close the transport connection at any ! time. For example, a client may have started to send a new request at the same time that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed while it was idle, but from the client's point of view, a request --- 2409,2415 ---- network. A client, server, or proxy MAY close the transport connection at any ! time. For example, a client might have started to send a new request at the same time that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed while it was idle, but from the client's point of view, a request *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_040: *** 2482,2488 **** allow an end-client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. ! In some cases, it may either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body. --- 2487,2493 ---- allow an end-client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. ! In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body. *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_041: *** 2507,2513 **** Failed) status or a 100 (Continue) status. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the client ! should not wait for an indefinite period before sending the request body. Requirements for HTTP/1.1 origin servers: --- 2512,2518 ---- Failed) status or a 100 (Continue) status. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the client ! SHOULD NOT wait for an indefinite period before sending the request body. Requirements for HTTP/1.1 origin servers: *************** Reason: This is apparently a normative SHOULD NOT. --------------- ** issue MMS_AUDIT_ITEM_042: *** 2543,2551 **** an error status before reading the entire request body from the transport connection, then the server SHOULD NOT close the transport connection until it has read the entire request, or until ! the client closes the connection. Otherwise, the client may not reliably receive the response message. However, this requirement ! should not be construed as preventing a server from defending itself against denial-of-service attacks, or from badly broken client implementations. --- 2548,2556 ---- an error status before reading the entire request body from the transport connection, then the server SHOULD NOT close the transport connection until it has read the entire request, or until ! the client closes the connection. Otherwise, the client might not reliably receive the response message. However, this requirement ! is not to be construed as preventing a server from defending itself against denial-of-service attacks, or from badly broken client implementations. *************** Reason: (1) This "may" is not intended to be normative. (2) This "should not" is not intended to be normative (i.e., it does not specify something that an implementation "SHOULD NOT" do, it explains how to interpret a requirement). --------------- ** issue MMS_AUDIT_ITEM_043: *** 2651,2662 **** Implementers should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the ! user to be aware of any actions they may take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD ! methods should never have the significance of taking an action other ! than retrieval. These methods should be considered "safe." This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. --- 2656,2667 ---- Implementers should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the ! user to be aware of any actions they might take which might have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD ! methods SHOULD NOT have the significance of taking an action other ! than retrieval. These methods ought to be considered "safe." This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. *************** Reason: (1) This "may" is not intended to be normative. (2) This is apparently a normative SHOULD NOT. (3) This "should" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_044: *** 2670,2680 **** 9.1.2 Idempotent Methods ! Methods may also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and ! DELETE share this property. Also, the methods OPTIONS and TRACE should ! have no side effects, and so are inherently idempotent. However, it is possible that a sequence of several requests is non- idempotent, even if all of the methods executed in that sequence is --- 2675,2685 ---- 9.1.2 Idempotent Methods ! Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and ! DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD ! NOT have side effects, and so are inherently idempotent. However, it is possible that a sequence of several requests is non- idempotent, even if all of the methods executed in that sequence is *************** Reason: (1) This "may" is not intended to be normative; it doesn't apply to any specific method(s). (2) This is apparently a normative SHOULD NOT. --------------- ** issue MMS_AUDIT_ITEM_045: *** 2709,2715 **** If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification ! does not define any use for such a body, future extensions to HTTP may use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body. --- 2714,2720 ---- If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification ! does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body. *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_046: *** 2730,2736 **** (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a body ! is not defined by this specification, but may be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of "0". --- 2735,2741 ---- (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a body ! is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of "0". *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_047: *** 2793,2800 **** often used for testing hypertext links for validity, accessibility, and recent modification. ! The response to a HEAD request may be cachable in the sense that the ! information contained in the response may be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then --- 2798,2805 ---- often used for testing hypertext links for validity, accessibility, and recent modification. ! The response to a HEAD request MAY be cachable in the sense that the ! information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then *************** Reason: (1) This is apparently a normative MAY. (2) This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_048: *** 2847,2853 **** (See Other) response can be used to direct the user agent to retrieve a cachable resource. ! POST requests must obey the message transmission requirements set out in section 8.2. See section 15.1.3 for security considerations. --- 2852,2858 ---- (See Other) response can be used to direct the user agent to retrieve a cachable resource. ! POST requests MUST obey the message transmission requirements set out in section 8.2. See section 15.1.3 for security considerations. *************** Reason: This is apparently a normative MUST. --------------- ** issue MMS_AUDIT_ITEM_049: *** 2878,2890 **** in such cases. If the request passes through a cache and the Request-URI identifies one ! or more currently cached entities, those entries should be treated as stale. Responses to this method are not cachable. The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. ! That resource may be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT --- 2883,2895 ---- in such cases. If the request passes through a cache and the Request-URI identifies one ! or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cachable. The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. ! That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT *************** Reason: (1) This is apparently a normative SHOULD. (2) This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_050: *** 2894,2908 **** decision regarding whether or not to redirect the request. A single resource MAY be identified by many different URIs. For example, ! an article may have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, ! a PUT request on a general URI may result in several other URIs being defined by the origin server. HTTP/1.1 does not define how a PUT method affects the state of an origin server. ! PUT requests must obey the message transmission requirements set out in section 8.2. Unless otherwise specified for a particular entity-header, the entity- --- 2899,2913 ---- decision regarding whether or not to redirect the request. A single resource MAY be identified by many different URIs. For example, ! an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, ! a PUT request on a general URI might result in several other URIs being defined by the origin server. HTTP/1.1 does not define how a PUT method affects the state of an origin server. ! PUT requests MUST obey the message transmission requirements set out in section 8.2. Unless otherwise specified for a particular entity-header, the entity- *************** Reason: (1) This "may" is not intended to be normative. (2) This "may" is not intended to be normative (since it's still part of the example). (3) This is apparently a normative MUST. --------------- ** issue MMS_AUDIT_ITEM_051: *** 2917,2930 **** intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been ! completed successfully. However, the server SHOULD not indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location. A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet ! been enacted, or 204 (No Content) if the response is OK but does not ! include an entity. Fielding, et al [Page 48] --- 2922,2935 ---- intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been ! completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location. A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet ! been enacted, or 204 (No Content) if the action has been enacted ! but the response does not include an entity. Fielding, et al [Page 48] *************** Reason: (1) "SHOULD NOT", not "SHOULD not" (2) "response is OK" is an undefined term --------------- ** issue MMS_AUDIT_ITEM_052: *** 2932,2938 **** INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998 If the request passes through a cache and the Request-URI identifies one ! or more currently cached entities, those entries should be treated as stale. Responses to this method are not cachable. --- 2937,2943 ---- INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998 If the request passes through a cache and the Request-URI identifies one ! or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cachable. *************** Reason: This is apparently a normative SHOULD. --------------- ** issue MMS_AUDIT_ITEM_053: *** 3001,3007 **** 10.1.1 100 Continue ! The client may continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has --- 3006,3012 ---- 10.1.1 100 Continue ! The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has *************** Reason: This is apparently a normative SHOULD, not a "may". The same requirement is stated (in somewhat more complex terms) two sentences later. --------------- ** issue MMS_AUDIT_ITEM_054: *** 3019,3027 **** header field immediately after the empty line which terminates the 101 response. ! The protocol should only be switched when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over ! older versions, and switching to a real-time, synchronous protocol may be advantageous when delivering resources that use such features. --- 3024,3032 ---- header field immediately after the empty line which terminates the 101 response. ! The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over ! older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features. *************** Reason: (1) This is apparently a normative SHOULD. (2) This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_055: *** 3060,3066 **** returned in the entity of the response, with the most specific URL for the resource given by a Location header field. The origin server MUST create the resource before returning the 201 status code. If the action ! cannot be carried out immediately, the server should respond with 202 (Accepted) response instead. --- 3065,3071 ---- returned in the entity of the response, with the most specific URL for the resource given by a Location header field. The origin server MUST create the resource before returning the 201 status code. If the action ! cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead. *************** Reason: This is apparently a normative SHOULD. --------------- ** issue MMS_AUDIT_ITEM_056: *** 3067,3074 **** 10.2.3 202 Accepted The request has been accepted for processing, but the processing has not ! been completed. The request MAY or MAY NOT eventually be acted upon, as ! it MAY be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this. --- 3072,3079 ---- 10.2.3 202 Accepted The request has been accepted for processing, but the processing has not ! been completed. The request might or might not eventually be acted upon, as ! it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this. *************** Reason: These "MAY"s are not really normative. --------------- ** issue MMS_AUDIT_ITEM_057: *** 3088,3094 **** set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information ! about the resource MAY result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK). --- 3093,3099 ---- set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information ! about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK). *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_058: *** 3096,3102 **** 10.2.5 204 No Content The server has fulfilled the request but does not need to return an ! entity-body, and may want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant. --- 3101,3107 ---- 10.2.5 204 No Content The server has fulfilled the request but does not need to return an ! entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant. *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_059: *** 3131,3138 **** 10.2.7 206 Partial Content The server has fulfilled the partial GET request for the resource. The ! request must have included a Range header field (section 14.35) ! indicating the desired range, and may have included an If-Range header field (section 14.27) to make the request conditional. The response MUST include the following header fields: --- 3136,3143 ---- 10.2.7 206 Partial Content The server has fulfilled the partial GET request for the resource. The ! request MUST have included a Range header field (section 14.35) ! indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional. The response MUST include the following header fields: *************** Reason: This is apparently a normative MAY. (But perhaps this is borderline.) --------------- ** issue MMS_AUDIT_ITEM_060: *** 3202,3208 **** the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, ! selection of the most appropriate choice may be performed automatically. However, this specification does not define any standard for such automatic selection. --- 3207,3213 ---- the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, ! selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection. *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_061: *** 3244,3250 **** 10.3.3 302 Found The requested resource resides temporarily under a different URI. Since ! the redirection may be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cachable if indicated by a Cache-Control or Expires header field. --- 3249,3255 ---- 10.3.3 302 Found The requested resource resides temporarily under a different URI. Since ! the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cachable if indicated by a Cache-Control or Expires header field. *************** Reason: This is apparently a normative MAY. (Borderline?) --------------- ** issue MMS_AUDIT_ITEM_062: *** 3262,3268 **** a 302 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request. ! Note: RFC 1945 and RFC 2068 specify that the client should not change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the --- 3267,3273 ---- a 302 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request. ! Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the *************** Reason: This "should not" isn't very explicit or obvious, at least in RFC2068. --------------- ** issue MMS_AUDIT_ITEM_063: *** 3278,3285 **** exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 ! response is not cachable, but the response to the second (redirected) ! request MAY be cachable. If the new URI is a location, its URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of --- 3283,3290 ---- exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 ! response MUST NOT be cached, but the response to the second (redirected) ! request might be cachable. If the new URI is a location, its URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of *************** Reason: (1) The "is not cachable" is normative, and so should be "MUST NOT be cached" (2) The "MAY" is not normative because we don't know whether the second response is cachable without more details about it. I.e., we can't say at this point definitively that it MAY be cached. --------------- ** issue MMS_AUDIT_ITEM_064: *** 3349,3355 **** 10.3.7 307 Temporary Redirect The requested resource resides temporarily under a different URI. Since ! the redirection may be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cachable if indicated by a Cache-Control or Expires header field. --- 3354,3360 ---- 10.3.7 307 Temporary Redirect The requested resource resides temporarily under a different URI. Since ! the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cachable if indicated by a Cache-Control or Expires header field. *************** Reason: This is apparently a normative MAY. (Borderline?) --------------- ** issue MMS_AUDIT_ITEM_065: *** 3369,3375 **** conditions under which the request was issued. Note: Many pre-HTTP/1.1 user agents do not understand the 307 ! status. An appropriate response entity should contain the information necessary for a user to repeat the original request on the new URL. --- 3374,3380 ---- conditions under which the request was issued. Note: Many pre-HTTP/1.1 user agents do not understand the 307 ! status. An appropriate response entity SHOULD contain the information necessary for a user to repeat the original request on the new URL. *************** Reason: This is apparently a normative SHOULD. --------------- ** issue MMS_AUDIT_ITEM_066: *** 3384,3390 **** display any included entity to the user. Note: If the client is sending data, a server implementation using ! TCP should be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send a --- 3389,3395 ---- display any included entity to the user. Note: If the client is sending data, a server implementation using ! TCP SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send a *************** Reason: This is apparently a normative SHOULD, although perhaps it could be phrased somewhat more explicitly. --------------- ** issue MMS_AUDIT_ITEM_067: *** 3410,3416 **** credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was ! given in the response, since that entity MAY include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" .. --- 3415,3421 ---- credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was ! given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" .. *************** Reason: This "MAY" is explanatory, not normative. (Section 4.3 already allows a response to include an entity unless specifically prohibited). --------------- ** issue MMS_AUDIT_ITEM_068: *** 3464,3470 **** from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of the ! user agent, selection of the most appropriate choice may be performed automatically. However, this specification does not define any standard for such automatic selection. --- 3469,3475 ---- from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of the ! user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection. *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_069: *** 3506,3512 **** resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the ! user or user agent to fix the problem; however, that may not be possible and is not required. Conflicts are most likely to occur in response to a PUT request. If --- 3511,3517 ---- resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the ! user or user agent to fix the problem; however, that might not be possible and is not required. Conflicts are most likely to occur in response to a PUT request. If *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_070: *** 3521,3527 **** 10.4.11 410 Gone The requested resource is no longer available at the server and no ! forwarding address is known. This condition SHOULD be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition --- 3526,3532 ---- 10.4.11 410 Gone The requested resource is no longer available at the server and no ! forwarding address is known. This condition is expected to be permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition *************** Reason: This "SHOULD" has no normative effect. The next sentence does contain a normative SHOULD that derives from the fact that the condition is permanent. --------------- ** issue MMS_AUDIT_ITEM_071: *** 3561,3572 **** 10.4.14 413 Request Entity Too Large The server is refusing to process a request because the request entity ! is larger than the server is willing or able to process . The server may close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry-After header field to indicate that it is temporary and after what time the ! client may try again. 10.4.15 414 Request-URI Too Long --- 3566,3577 ---- 10.4.14 413 Request Entity Too Large The server is refusing to process a request because the request entity ! is larger than the server is willing or able to process . The server MAY close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry-After header field to indicate that it is temporary and after what time the ! client MAY try again. 10.4.15 414 Request-URI Too Long *************** Reason: (1) This is apparently a normative MAY. (2) This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_072: *** 3656,3662 **** The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If ! known, the length of the delay may be indicated in a Retry-After header. Fielding, et al [Page 60] --- 3661,3667 ---- The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If ! known, the length of the delay MAY be indicated in a Retry-After header. Fielding, et al [Page 60] *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_073: *** 3691,3697 **** 11 Access Authentication ! HTTP provides several optional challenge-response authentication mechanisms which MAY be used by a server to challenge a client request and by a client to provide authentication information. The general framework for access authentication, and the specification of "basic" --- 3696,3702 ---- 11 Access Authentication ! HTTP provides several OPTIONAL challenge-response authentication mechanisms which MAY be used by a server to challenge a client request and by a client to provide authentication information. The general framework for access authentication, and the specification of "basic" *************** Reason: OPTIONAL is a keyword as used here; authentication support for any specific authentication mechanism is not mandatory. --------------- ** issue MMS_AUDIT_ITEM_074: *** 3869,3875 **** require us to be able to relax the goal of semantic transparency. The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary. However, because non- ! transparent operation may confuse non-expert users, and may be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed --- 3874,3880 ---- require us to be able to relax the goal of semantic transparency. The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary. However, because non- ! transparent operation might confuse non-expert users, and might be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_075: *** 3893,3901 **** A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency. ! Note: The server, cache, or client implementer may be faced with design decisions not explicitly discussed in this specification. If ! a decision may affect semantic transparency, the implementer ought to err on the side of maintaining transparency unless a careful and complete analysis shows significant benefits in breaking transparency. --- 3898,3906 ---- A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency. ! Note: The server, cache, or client implementer might be faced with design decisions not explicitly discussed in this specification. If ! a decision might affect semantic transparency, the implementer ought to err on the side of maintaining transparency unless a careful and complete analysis shows significant benefits in breaking transparency. *************** Reason: (1) This "may" is not intended to be normative. (2) This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_076: *** 3926,3932 **** 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; --- 3931,3937 ---- 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; *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_077: *** 3954,3964 **** 13.1.2 Warnings Whenever a cache returns a response that is neither first-hand nor ! "fresh enough" (in the sense of condition 2 in section 13.1.1), it must attach a warning to that effect, using a Warning response-header. This warning allows clients to take appropriate action. ! Warnings may be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguish these responses from true failures. --- 3959,3969 ---- 13.1.2 Warnings Whenever a cache returns a response that is neither first-hand nor ! "fresh enough" (in the sense of condition 2 in section 13.1.1), it MUST attach a warning to that effect, using a Warning response-header. This warning allows clients to take appropriate action. ! Warnings MAY be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguish these responses from true failures. *************** Reason: (1) This is apparently a normative MUST. (2) This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_078: *** 3978,3984 **** deleted after a successful revalidation. Warnings are assigned 3-digit code numbers. The first digit indicates ! whether the Warning must or must not be deleted from a cached response after it is successfully revalidated. This specification defines the code numbers and meanings of each currently assigned warning, allowing a client or cache to take automated action in some (but not all) cases. --- 3983,3989 ---- deleted after a successful revalidation. Warnings are assigned 3-digit code numbers. The first digit indicates ! whether the Warning MUST or MUST NOT be deleted from a cached response after it is successfully revalidated. This specification defines the code numbers and meanings of each currently assigned warning, allowing a client or cache to take automated action in some (but not all) cases. *************** Reason: These are normative MUSTs. --------------- ** issue MMS_AUDIT_ITEM_079: *** 3988,4003 **** extra warning-date field, which prevents a future HTTP/1.1 recipient from believing an erroneously cached Warning. ! Warnings also carry a warning text. The text may be in any appropriate natural language (perhaps based on the client's Accept headers), and ! include an optional indication of what character set is used. ! Multiple warnings may be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code ! number. For example, a server may provide the same warning with texts in both English and Basque. ! When multiple warnings are attached to a response, it may not be practical or reasonable to display all of them to the user. This version of HTTP does not specify strict priority rules for deciding which warnings to display and in what order, but does suggest some heuristics. --- 3993,4008 ---- extra warning-date field, which prevents a future HTTP/1.1 recipient from believing an erroneously cached Warning. ! Warnings also carry a warning text. The text MAY be in any appropriate natural language (perhaps based on the client's Accept headers), and ! include an OPTIONAL indication of what character set is used. ! Multiple warnings MAY be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code ! number. For example, a server might provide the same warning with texts in both English and Basque. ! When multiple warnings are attached to a response, it might not be practical or reasonable to display all of them to the user. This version of HTTP does not specify strict priority rules for deciding which warnings to display and in what order, but does suggest some heuristics. *************** Reason: (1) This is apparently a normative MAY. (2) OPTIONAL is a keyword as used here. (3) OPTIONAL is a keyword as used here. (4) This "may" is not intended to be normative. (5) This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_080: *** 4010,4016 **** The basic cache mechanisms in HTTP/1.1 (server-specified expiration times and validators) are implicit directives to caches. In some cases, ! a server or client may need to provide explicit directives to the HTTP caches. We use the Cache-Control header for this purpose. The Cache-Control header allows a client or server to transmit a variety --- 4015,4021 ---- The basic cache mechanisms in HTTP/1.1 (server-specified expiration times and validators) are implicit directives to caches. In some cases, ! a server or client might need to provide explicit directives to the HTTP caches. We use the Cache-Control header for this purpose. The Cache-Control header allows a client or server to transmit a variety *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_081: *** 4017,4023 **** of directives in either requests or responses. These directives typically override the default caching algorithms. As a general rule, if there is any apparent conflict between header values, the most ! restrictive interpretation should be applied (that is, the one that is most likely to preserve semantic transparency). However, in some cases, Cache-Control directives are explicitly specified as weakening the approximation of semantic transparency (for example, "max-stale" or --- 4022,4028 ---- of directives in either requests or responses. These directives typically override the default caching algorithms. As a general rule, if there is any apparent conflict between header values, the most ! restrictive interpretation is applied (that is, the one that is most likely to preserve semantic transparency). However, in some cases, Cache-Control directives are explicitly specified as weakening the approximation of semantic transparency (for example, "max-stale" or *************** Reason: Since this is introduced as "a general rule" with later exceptions, and because it's basically explanatory text, this "should" is not intended as a normative requirement. --------------- ** issue MMS_AUDIT_ITEM_082: *** 4032,4046 **** 13.1.4 Explicit User Agent Warnings Many user agents make it possible for users to override the basic ! caching mechanisms. For example, the user agent may allow the user to specify that cached entities (even explicitly stale ones) are never validated. Or the user agent might habitually add "Cache-Control: max- ! stale=3600" to every request. The user should have to explicitly request either non-transparent behavior, or behavior that results in abnormally ! ineffective caching. If the user has overridden the basic caching mechanisms, the user agent ! should explicitly indicate to the user whenever this results in the display of information that might not meet the server's transparency requirements (in particular, if the displayed entity is known to be stale). Since the protocol normally allows the user agent to determine --- 4037,4052 ---- 13.1.4 Explicit User Agent Warnings Many user agents make it possible for users to override the basic ! caching mechanisms. For example, the user agent might allow the user to specify that cached entities (even explicitly stale ones) are never validated. Or the user agent might habitually add "Cache-Control: max- ! stale=3600" to every request. The user agent SHOULD NOT default to either non-transparent behavior, or behavior that results in abnormally ! ineffective caching, but MAY be explicitly configured to do so by ! an explicit action of the user. If the user has overridden the basic caching mechanisms, the user agent ! SHOULD explicitly indicate to the user whenever this results in the display of information that might not meet the server's transparency requirements (in particular, if the displayed entity is known to be stale). Since the protocol normally allows the user agent to determine *************** Reason: (1) This "may" is not intended to be normative. (2) This is a normative requirement, best stated as a "SHOULD NOT" (3) ... but we do allow explicit configuration to override default (4) This is apparently a normative SHOULD. --------------- ** issue MMS_AUDIT_ITEM_083: *** 4050,4056 **** other indicator. If the user has overridden the caching mechanisms in a way that would ! abnormally reduce the effectiveness of caches, the user agent should continually display an indication (for example, a picture of currency in flames) so that the user does not inadvertently consume excess resources or suffer from excessive latency. --- 4056,4062 ---- other indicator. If the user has overridden the caching mechanisms in a way that would ! abnormally reduce the effectiveness of caches, the user agent SHOULD continually display an indication (for example, a picture of currency in flames) so that the user does not inadvertently consume excess resources or suffer from excessive latency. *************** Reason: This is apparently a normative SHOULD. --------------- ** issue MMS_AUDIT_ITEM_084: *** 4058,4074 **** 13.1.5 Exceptions to the Rules and Warnings ! In some cases, the operator of a cache may choose to configure it to return stale responses even when not requested by clients. This decision ! should not be made lightly, but may be necessary for reasons of availability or performance, especially when the cache is poorly connected to the origin server. Whenever a cache returns a stale response, it MUST mark it as such (using a Warning header). This allows ! the client software to alert the user that there may be a potential problem. It also allows the user agent to take steps to obtain a first-hand or ! fresh response. For this reason, a cache should not return a stale response if the client explicitly requests a first-hand or fresh one, unless it is impossible to comply for technical or policy reasons. --- 4064,4080 ---- 13.1.5 Exceptions to the Rules and Warnings ! In some cases, the operator of a cache MAY choose to configure it to return stale responses even when not requested by clients. This decision ! ought not to be made lightly, but might be necessary for reasons of availability or performance, especially when the cache is poorly connected to the origin server. Whenever a cache returns a stale response, it MUST mark it as such (using a Warning header). This allows ! the client software to alert the user that there might be a potential problem. It also allows the user agent to take steps to obtain a first-hand or ! fresh response. For this reason, a cache SHOULD NOT return a stale response if the client explicitly requests a first-hand or fresh one, unless it is impossible to comply for technical or policy reasons. *************** Reason: (1) This is apparently a normative MAY. (2) This "may" is not intended to be normative. (3) This "may" is not intended to be normative. (4) This is apparently a normative SHOULD NOT. --------------- ** issue MMS_AUDIT_ITEM_085: *** 4077,4090 **** While the origin server (and to a lesser extent, intermediate caches, by their contribution to the age of a response) are the primary source of ! expiration information, in some cases the client may need to control a cache's decision about whether to return a cached response without validating it. Clients do this using several directives of the Cache- Control header. ! A client's request may specify the maximum age it is willing to accept of an unvalidated response; specifying a value of zero forces the ! cache(s) to revalidate all responses. A client may also specify the Fielding, et al [Page 67] --- 4083,4096 ---- While the origin server (and to a lesser extent, intermediate caches, by their contribution to the age of a response) are the primary source of ! expiration information, in some cases the client might need to control a cache's decision about whether to return a cached response without validating it. Clients do this using several directives of the Cache- Control header. ! A client's request MAY specify the maximum age it is willing to accept of an unvalidated response; specifying a value of zero forces the ! cache(s) to revalidate all responses. A client MAY also specify the Fielding, et al [Page 67] *************** Reason: (1) This "may" is not intended to be normative. (2) This is apparently a normative MAY. (3) This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_086: *** 4094,4103 **** increase constraints on the behavior of caches, and so cannot further relax the cache's approximation of semantic transparency. ! A client may also specify that it will accept stale responses, up to some maximum amount of staleness. This loosens the constraints on the ! caches, and so may violate the origin server's specified constraints on ! semantic transparency, but may be necessary to support disconnected operation, or high availability in the face of poor connectivity. --- 4100,4109 ---- increase constraints on the behavior of caches, and so cannot further relax the cache's approximation of semantic transparency. ! A client MAY also specify that it will accept stale responses, up to some maximum amount of staleness. This loosens the constraints on the ! caches, and so might violate the origin server's specified constraints on ! semantic transparency, but might be necessary to support disconnected operation, or high availability in the face of poor connectivity. *************** Reason: (1) This is apparently a normative MAY. (2) This "may" is not intended to be normative. (3) This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_087: *** 4109,4115 **** HTTP caching works best when caches can entirely avoid making requests to the origin server. The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future, ! indicating that a response may be used to satisfy subsequent requests. In other words, a cache can return a fresh response without first contacting the server. --- 4115,4121 ---- HTTP caching works best when caches can entirely avoid making requests to the origin server. The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future, ! indicating that a response MAY be used to satisfy subsequent requests. In other words, a cache can return a fresh response without first contacting the server. *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_088: *** 4124,4136 **** client. If an origin server wishes to force a semantically transparent cache to ! validate every request, it may assign an explicit expiration time in the past. This means that the response is always stale, and so the cache SHOULD validate it before using it for subsequent requests. See section 14.9.4 for a more restrictive way to force revalidation. If an origin server wishes to force any HTTP/1.1 cache, no matter how it ! is configured, to validate every request, it should use the "must- revalidate" Cache-Control directive (see section 14.9). Servers specify explicit expiration times using either the Expires --- 4130,4142 ---- client. If an origin server wishes to force a semantically transparent cache to ! validate every request, it MAY assign an explicit expiration time in the past. This means that the response is always stale, and so the cache SHOULD validate it before using it for subsequent requests. See section 14.9.4 for a more restrictive way to force revalidation. If an origin server wishes to force any HTTP/1.1 cache, no matter how it ! is configured, to validate every request, it SHOULD use the "must- revalidate" Cache-Control directive (see section 14.9). Servers specify explicit expiration times using either the Expires *************** Reason: (1) This is apparently a normative MAY. (2) This is apparently a normative SHOULD. (Perhaps this is a MAY?) --------------- ** issue MMS_AUDIT_ITEM_089: *** 4158,4165 **** algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints ! on their results. Since heuristic expiration times may compromise ! semantic transparency, they should be used cautiously, and we encourage origin servers to provide explicit expiration times as much as possible. --- 4164,4171 ---- algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints ! on their results. Since heuristic expiration times might compromise ! semantic transparency, they ought to be used cautiously, and we encourage origin servers to provide explicit expiration times as much as possible. *************** Reason: (1) This "may" is not intended to be normative. (2) This "should" is not intended to be normative (there is no specific requirement here, beyond the vague "cautiously.") --------------- ** issue MMS_AUDIT_ITEM_090: *** 4172,4178 **** In this discussion, we use the term "now" to mean "the current value of the clock at the host performing the calculation." Hosts that use HTTP, ! but especially hosts running origin servers and caches, should use NTP [28] or some similar protocol to synchronize their clocks to a globally accurate time standard. --- 4178,4184 ---- In this discussion, we use the term "now" to mean "the current value of the clock at the host performing the calculation." Hosts that use HTTP, ! but especially hosts running origin servers and caches, SHOULD use NTP [28] or some similar protocol to synchronize their clocks to a globally accurate time standard. *************** Reason: This is apparently a normative SHOULD. --------------- ** issue MMS_AUDIT_ITEM_091: *** 4215,4221 **** and as long as we have either nearly synchronized clocks or all-HTTP/1.1 paths, one gets a reliable (conservative) result. ! Because of network-imposed delays, some significant interval may pass between the time that a server generates a response and the time it is received at the next outbound cache or client. If uncorrected, this delay could result in improperly low ages. --- 4221,4227 ---- and as long as we have either nearly synchronized clocks or all-HTTP/1.1 paths, one gets a reliable (conservative) result. ! Because of network-imposed delays, some significant interval might pass between the time that a server generates a response and the time it is received at the next outbound cache or client. If uncorrected, this delay could result in improperly low ages. *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_092: *** 4259,4265 **** The current_age of a cache entry is calculated by adding the amount of time (in seconds) since the cache entry was last validated by the origin server to the corrected_initial_age. When a response is generated from a ! cache entry, the server must include a single Age header field in the response with a value equal to the cache entry's current_age. The presence of an Age header field in a response implies that a --- 4265,4271 ---- The current_age of a cache entry is calculated by adding the amount of time (in seconds) since the cache entry was last validated by the origin server to the corrected_initial_age. When a response is generated from a ! cache entry, the server MUST include a single Age header field in the response with a value equal to the cache entry's current_age. The presence of an Age header field in a response implies that a *************** Reason: This is apparently a normative MUST. --------------- ** issue MMS_AUDIT_ITEM_093: *** 4301,4307 **** (see section 14.9.3) appears in the response, and the response does not include other restrictions on caching, the cache MAY compute a freshness lifetime using a heuristic. If the value is greater than 24 hours, the ! cache must attach Warning 113 to any response whose age is more than 24 hours if such warning has not already been added. Also, if the response does have a Last-Modified time, the heuristic --- 4307,4313 ---- (see section 14.9.3) appears in the response, and the response does not include other restrictions on caching, the cache MAY compute a freshness lifetime using a heuristic. If the value is greater than 24 hours, the ! cache MUST attach Warning 113 to any response whose age is more than 24 hours if such warning has not already been added. Also, if the response does have a Last-Modified time, the heuristic *************** Reason: This is apparently a normative MUST. --------------- ** issue MMS_AUDIT_ITEM_094: *** 4327,4333 **** If a cache has two fresh responses for the same representation with different validators, it MUST use the one with the more recent Date ! header. This situation may arise because the cache is pooling responses Fielding, et al [Page 71] --- 4333,4339 ---- If a cache has two fresh responses for the same representation with different validators, it MUST use the one with the more recent Date ! header. This situation might arise because the cache is pooling responses Fielding, et al [Page 71] *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_095: *** 4340,4348 **** 13.2.6 Disambiguating Multiple Responses ! Because a client may be receiving responses via multiple paths, so that some responses flow through one set of caches and other responses flow ! through a different set of caches, a client may receive responses in an order different from that in which the origin server sent them. We would like the client to use the most recently generated response, even if older responses are still apparently fresh. --- 4346,4354 ---- 13.2.6 Disambiguating Multiple Responses ! Because a client might be receiving responses via multiple paths, so that some responses flow through one set of caches and other responses flow ! through a different set of caches, a client might receive responses in an order different from that in which the origin server sent them. We would like the client to use the most recently generated response, even if older responses are still apparently fresh. *************** Reason: (1) This "may" is not intended to be normative. (2) This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_096: *** 4365,4372 **** to force any intermediate caches to obtain a new copy from the origin server. ! If the Date values are equal, then the client may use either response ! (or may, if it is being extremely prudent, request a new response). Servers MUST NOT depend on clients being able to choose deterministically between responses generated during the same second, if their expiration times overlap. --- 4371,4378 ---- to force any intermediate caches to obtain a new copy from the origin server. ! If the Date values are equal, then the client MAY use either response ! (or MAY, if it is being extremely prudent, request a new response). Servers MUST NOT depend on clients being able to choose deterministically between responses generated during the same second, if their expiration times overlap. *************** Reason: (1) This is apparently a normative MAY. (2) This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_097: *** 4432,4441 **** 13.3.2 Entity Tag Cache Validators The ETag response-header field value, an entity tag, provides for an ! "opaque" cache validator. This may allow more reliable validation in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, or ! where the origin server wishes to avoid certain paradoxes that may arise from the use of modification dates. Entity Tags are described in section 3.11. The headers used with entity --- 4438,4447 ---- 13.3.2 Entity Tag Cache Validators The ETag response-header field value, an entity tag, provides for an ! "opaque" cache validator. This might allow more reliable validation in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, or ! where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates. Entity Tags are described in section 3.11. The headers used with entity *************** Reason: (1) This "may" is not intended to be normative. (2) This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_098: *** 4456,4462 **** INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998 ! However, there may be cases when a server prefers to change the validator only on semantically significant changes, and not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is a "weak validator." --- 4462,4468 ---- INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998 ! However, there might be cases when a server prefers to change the validator only on semantically significant changes, and not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is a "weak validator." *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_099: *** 4474,4480 **** An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible that ! the resource may be modified twice during a single second. Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects; for --- 4480,4486 ---- An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible that ! the resource might be modified twice during a single second. Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects; for *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_100: *** 4490,4496 **** usable in contexts that do not depend on exact equality of an entity. For example, either kind is usable for a conditional GET of a full entity. However, only a strong validator is usable for a sub-range ! retrieval, since otherwise the client may end up with an internally inconsistent entity. The only function that the HTTP/1.1 protocol defines on validators is --- 4496,4502 ---- usable in contexts that do not depend on exact equality of an entity. For example, either kind is usable for a conditional GET of a full entity. However, only a strong validator is usable for a sub-range ! retrieval, since otherwise the client might end up with an internally inconsistent entity. The only function that the HTTP/1.1 protocol defines on validators is *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_101: *** 4498,4508 **** whether the comparison context allows the use of weak validators or not: . The strong comparison function: in order to be considered equal, ! both validators must be identical in every way, and neither may be weak. . The weak comparison function: in order to be considered equal, both ! validators must be identical in every way, but either or both of ! them may be tagged as "weak" without affecting the result. The weak comparison function MAY be used for simple (non-subrange) GET requests. The strong comparison function MUST be used in all other cases. --- 4504,4514 ---- whether the comparison context allows the use of weak validators or not: . The strong comparison function: in order to be considered equal, ! both validators MUST be identical in every way, and both MUST NOT be weak. . The weak comparison function: in order to be considered equal, both ! validators MUST be identical in every way, but either or both of ! them MAY be tagged as "weak" without affecting the result. The weak comparison function MAY be used for simple (non-subrange) GET requests. The strong comparison function MUST be used in all other cases. *************** Reason: (1) This is apparently a normative MUST. (2) This is apparently a normative MUST. (3) This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_102: *** 4549,4560 **** value equal to its Last-Modified time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from different clocks, or at somewhat different times ! during the preparation of the response. An implementation may use a value larger than 60 seconds, if it is believed that 60 seconds is too short. If a client wishes to perform a sub-range retrieval on a value for which ! it has only a Last-Modified time and no opaque validator, it may do this only if the Last-Modified time is strong in the sense described here. A cache or origin server receiving a conditional request, other than a --- 4555,4566 ---- value equal to its Last-Modified time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from different clocks, or at somewhat different times ! during the preparation of the response. An implementation MAY use a value larger than 60 seconds, if it is believed that 60 seconds is too short. If a client wishes to perform a sub-range retrieval on a value for which ! it has only a Last-Modified time and no opaque validator, it MAY do this only if the Last-Modified time is strong in the sense described here. A cache or origin server receiving a conditional request, other than a *************** Reason: (1) This is apparently a normative MAY. (2) This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_103: *** 4569,4575 **** 13.3.4 Rules for When to Use Entity Tags and Last-modified Dates We adopt a set of rules and recommendations for origin servers, clients, ! and caches regarding when various validator types should be used, and for what purposes. HTTP/1.1 origin servers: --- 4575,4581 ---- 13.3.4 Rules for When to Use Entity Tags and Last-modified Dates We adopt a set of rules and recommendations for origin servers, clients, ! and caches regarding when various validator types ought to be used, and for what purposes. HTTP/1.1 origin servers: *************** Reason: This "should" is not phrased as a normative requirement. --------------- ** issue MMS_AUDIT_ITEM_104: *** 4598,4606 **** Note: in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value for two different entities, or reusing a specific weak entity tag ! value for two semantically different entities. Cache entries may persist for arbitrarily long periods, regardless of expiration ! times, so it may be inappropriate to expect that a cache will never again attempt to validate an entry using a validator that it obtained at some point in the past. --- 4604,4612 ---- Note: in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value for two different entities, or reusing a specific weak entity tag ! value for two semantically different entities. Cache entries might persist for arbitrarily long periods, regardless of expiration ! times, so it might be inappropriate to expect that a cache will never again attempt to validate an entry using a validator that it obtained at some point in the past. *************** Reason: (1) This "may" is not intended to be normative. (2) This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_105: *** 4614,4620 **** requests (using If-Modified-Since). . If only a Last-Modified value has been provided by an HTTP/1.0 origin server, MAY use that value in subrange cache-conditional ! requests (using If-Unmodified-Since:). The user agent should provide a way to disable this, in case of difficulty. . If both an entity tag and a Last-Modified value have been provided by the origin server, SHOULD use both validators in cache- --- 4620,4626 ---- requests (using If-Modified-Since). . If only a Last-Modified value has been provided by an HTTP/1.0 origin server, MAY use that value in subrange cache-conditional ! requests (using If-Unmodified-Since:). The user agent SHOULD provide a way to disable this, in case of difficulty. . If both an entity tag and a Last-Modified value have been provided by the origin server, SHOULD use both validators in cache- *************** Reason: This is apparently a normative SHOULD. --------------- ** issue MMS_AUDIT_ITEM_106: *** 4668,4679 **** 13.4 Response Cachability Unless specifically constrained by a Cache-Control (section 14.9) ! directive, a caching system may always store a successful response (see ! section 13.8) as a cache entry, may return it without validation if it ! is fresh, and may return it after successful validation. If there is neither a cache validator nor an explicit expiration time associated with a response, we do not expect it to be cached, but certain caches ! may violate this expectation (for example, when little or no network connectivity is available). A client can usually detect that such a response was taken from a cache by comparing the Date header to the current time. --- 4674,4685 ---- 13.4 Response Cachability Unless specifically constrained by a Cache-Control (section 14.9) ! directive, a caching system MAY always store a successful response (see ! section 13.8) as a cache entry, MAY return it without validation if it ! is fresh, and MAY return it after successful validation. If there is neither a cache validator nor an explicit expiration time associated with a response, we do not expect it to be cached, but certain caches ! MAY violate this expectation (for example, when little or no network connectivity is available). A client can usually detect that such a response was taken from a cache by comparing the Date header to the current time. *************** Reason: (1) This is apparently a normative MAY. (2) This is apparently a normative MAY. (3) This is apparently a normative MAY. (4) This is apparently a normative MAY (i.e., caches MAY be configured to violate the expectation). --------------- ** issue MMS_AUDIT_ITEM_107: *** 4681,4693 **** Note that some HTTP/1.0 caches are known to violate this expectation without providing any Warning. ! However, in some cases it may be inappropriate for a cache to retain an ! entity, or to return it in response to a subsequent request. This may be because absolute semantic transparency is deemed necessary by the service author, or because of security or privacy considerations. Certain Cache-Control directives are therefore provided so that the server can indicate that certain resource entities, or portions thereof, ! may not be cached regardless of other considerations. Note that section 14.8 normally prevents a shared cache from saving and returning a response to a previous request if that request included an --- 4687,4699 ---- Note that some HTTP/1.0 caches are known to violate this expectation without providing any Warning. ! However, in some cases it might be inappropriate for a cache to retain an ! entity, or to return it in response to a subsequent request. This might be because absolute semantic transparency is deemed necessary by the service author, or because of security or privacy considerations. Certain Cache-Control directives are therefore provided so that the server can indicate that certain resource entities, or portions thereof, ! MUST NOT be cached regardless of other considerations. Note that section 14.8 normally prevents a shared cache from saving and returning a response to a previous request if that request included an *************** Reason: (1) This "may" is not intended to be normative. (2) This "may" is not intended to be normative. (3) This is apparently a normative MUST NOT (not a "may not"). --------------- ** issue MMS_AUDIT_ITEM_108: *** 4694,4700 **** Authorization header. A response received with a status code of 200, 203, 206, 300, 301 or 410 ! may be stored by a cache and used in reply to a subsequent request, Fielding, et al [Page 77] --- 4700,4706 ---- Authorization header. A response received with a status code of 200, 203, 206, 300, 301 or 410 ! MAY be stored by a cache and used in reply to a subsequent request, Fielding, et al [Page 77] *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_109: *** 4718,4724 **** response to requests, for use in responding to future requests. In many cases, a cache simply returns the appropriate parts of a response to the requester. However, if the cache holds a cache entry based on a previous ! response, it may have to combine parts of a new response with what is held in the cache entry. --- 4724,4730 ---- response to requests, for use in responding to future requests. In many cases, a cache simply returns the appropriate parts of a response to the requester. However, if the cache holds a cache entry based on a previous ! response, it might have to combine parts of a new response with what is held in the cache entry. *************** Reason: This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_110: *** 4727,4735 **** For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP headers into two categories: ! . End-to-end headers, which must be transmitted to the ultimate recipient of a request or response. End-to-end headers in responses ! must be stored as part of a cache entry and transmitted in any response formed from a cache entry. . Hop-by-hop headers, which are meaningful only for a single transport-level connection, and are not stored by caches or --- 4733,4741 ---- For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP headers into two categories: ! . End-to-end headers, which MUST be transmitted to the ultimate recipient of a request or response. End-to-end headers in responses ! MUST be stored as part of a cache entry and transmitted in any response formed from a cache entry. . Hop-by-hop headers, which are meaningful only for a single transport-level connection, and are not stored by caches or *************** Reason: (1) This is apparently a normative MUST. (2) This is apparently a normative MUST. --------------- ** issue MMS_AUDIT_ITEM_111: *** 4762,4768 **** INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998 A transparent proxy MUST NOT modify any of the following fields in a ! request or response, nor may it add any of these fields if not already present: . Content-Location --- 4768,4774 ---- INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998 A transparent proxy MUST NOT modify any of the following fields in a ! request or response, and it MUST NOT add any of these fields if not already present: . Content-Location *************** Reason: This is a normative requirement, best phrased as a MUST NOT. --------------- ** issue MMS_AUDIT_ITEM_112: *** 4773,4779 **** response: . Expires ! but it may add any of these fields if not already present. If an Expires header is added, it MUST be given a field-value identical to that of the Date header in that response. A proxy MUST NOT modify or add any of the following fields in a --- 4779,4785 ---- response: . Expires ! but it MAY add any of these fields if not already present. If an Expires header is added, it MUST be given a field-value identical to that of the Date header in that response. A proxy MUST NOT modify or add any of the following fields in a *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_113: *** 4788,4797 **** Warning 114 (Transformation applied) if one does not already appear in the response. ! Warning: unnecessary modification of end-to-end headers may cause authentication failures if stronger authentication mechanisms are introduced in later versions of HTTP. Such authentication ! mechanisms may rely on the values of header fields not listed here. The Content-Length field of a request or response is added or deleted according to the rules in section 4.4. A cache or non-caching proxy MUST --- 4794,4803 ---- Warning 114 (Transformation applied) if one does not already appear in the response. ! Warning: unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms are introduced in later versions of HTTP. Such authentication ! mechanisms MAY rely on the values of header fields not listed here. The Content-Length field of a request or response is added or deleted according to the rules in section 4.4. A cache or non-caching proxy MUST *************** Reason: (1) This "may" is not intended to be normative. (2) This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_114: *** 4803,4815 **** When a cache makes a validating request to a server, and the server provides a 304 (Not Modified) response or a 206 (Partial Content) ! response, the cache must construct a response to send to the requesting client. In the status code is 304 (Not Modified), the cache uses the entity-body stored in the cache entry as the entity-body of this outgoing response. If the status code is 206 (Partial Content) and the ETag or Last- ! Modified headers match exactly, see 13.5.4, the cache may combine the contents stored in the cache entry with the new contents received in the response and use the result as the entity-body of this outgoing response, see 13.5.4. --- 4809,4821 ---- When a cache makes a validating request to a server, and the server provides a 304 (Not Modified) response or a 206 (Partial Content) ! response, the cache then constructs a response to send to the requesting client. In the status code is 304 (Not Modified), the cache uses the entity-body stored in the cache entry as the entity-body of this outgoing response. If the status code is 206 (Partial Content) and the ETag or Last- ! Modified headers match exactly, see 13.5.4, the cache MAY combine the contents stored in the cache entry with the new contents received in the response and use the result as the entity-body of this outgoing response, see 13.5.4. *************** Reason: (1) This "must" is not intended to be normative. (Borderline?) (2) This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_115: *** 4823,4830 **** INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998 . any stored Warning headers with warn-code 1XX (see section 14.46) ! are deleted from the cache entry and the forwarded response. ! . any stored Warning headers with warn-code 2XX are retained in the cache entry and the forwarded response. . any end-to-end headers provided in the 304 or 206 response MUST replace the corresponding headers from the cache entry. --- 4829,4836 ---- INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998 . any stored Warning headers with warn-code 1XX (see section 14.46) ! MUST be deleted from the cache entry and the forwarded response. ! . any stored Warning headers with warn-code 2XX MUST be retained in the cache entry and the forwarded response. . any end-to-end headers provided in the 304 or 206 response MUST replace the corresponding headers from the cache entry. *************** Reason: (1) This is normative (MUST-level) (2) This is normative (MUST-level) --------------- ** issue MMS_AUDIT_ITEM_116: *** 4851,4860 **** 13.5.4 Combining Byte Ranges ! A response may transfer only a subrange of the bytes of an entity-body, either because the request included one or more Range specifications, or because a connection was broken prematurely. After several such ! transfers, a cache may have received several ranges of the same entity- body. If a cache has a stored non-empty set of subranges for an entity, and an --- 4857,4866 ---- 13.5.4 Combining Byte Ranges ! A response might transfer only a subrange of the bytes of an entity-body, either because the request included one or more Range specifications, or because a connection was broken prematurely. After several such ! transfers, a cache might have received several ranges of the same entity- body. If a cache has a stored non-empty set of subranges for an entity, and an *************** Reason: (1) This "may" is not intended to be normative. (2) This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_117: *** 4862,4875 **** new subrange with the existing set if both the following conditions are met: ! . Both the incoming response and the cache entry must have a cache validator. ! . The two cache validators must match using the strong comparison function (see section 13.3.3). ! If either requirement is not meant, the cache must use only the most recent partial response (based on the Date values transmitted with every response, and using the incoming response if these values are equal or ! missing), and must discard the other partial information. 13.6 Caching Negotiated Responses --- 4868,4881 ---- new subrange with the existing set if both the following conditions are met: ! . Both the incoming response and the cache entry MUST have a cache validator. ! . The two cache validators MUST match using the strong comparison function (see section 13.3.3). ! If either requirement is not meant, the cache MUST use only the most recent partial response (based on the Date values transmitted with every response, and using the incoming response if these values are equal or ! missing), and MUST discard the other partial information. 13.6 Caching Negotiated Responses *************** Reason: (1) This is apparently a normative MUST. (2) This is apparently a normative MUST. (3) This is apparently a normative MUST. (4) This is apparently a normative MUST. --------------- ** issue MMS_AUDIT_ITEM_118: *** 4912,4918 **** MUST NOT use a cached entry to satisfy the request unless it first relays the new request to the origin server in a conditional request and the server responds with 304 (Not Modified), including an entity tag or ! Content-Location that indicates which entity should be used. If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None- --- 4918,4924 ---- MUST NOT use a cached entry to satisfy the request unless it first relays the new request to the origin server in a conditional request and the server responds with 304 (Not Modified), including an entity tag or ! Content-Location that indicates the entity to be used. If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None- *************** Reason: This "should" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_119: *** 4934,4940 **** matches that of an existing cache entry for the same Request-URI, whose entity-tag differs from that of the existing entry, and whose Date is more recent than that of the existing entry, the existing entry SHOULD ! NOT be returned in response to future requests and should be deleted from the cache. --- 4940,4946 ---- matches that of an existing cache entry for the same Request-URI, whose entity-tag differs from that of the existing entry, and whose Date is more recent than that of the existing entry, the existing entry SHOULD ! NOT be returned in response to future requests and SHOULD be deleted from the cache. *************** Reason: This is apparently a normative SHOULD. --------------- ** issue MMS_AUDIT_ITEM_120: *** 4959,4967 **** 13.8 Errors or Incomplete Response Cache Behavior A cache that receives an incomplete response (for example, with fewer ! bytes of data than specified in a Content-Length header) may store the response. However, the cache MUST treat this as a partial response. ! Partial responses may be combined as described in section 13.5.4; the result might be a full response or might still be partial. A cache MUST NOT return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code. A cache MUST NOT --- 4965,4973 ---- 13.8 Errors or Incomplete Response Cache Behavior A cache that receives an incomplete response (for example, with fewer ! bytes of data than specified in a Content-Length header) MAY store the response. However, the cache MUST treat this as a partial response. ! Partial responses MAY be combined as described in section 13.5.4; the result might be a full response or might still be partial. A cache MUST NOT return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code. A cache MUST NOT *************** Reason: (1) This is apparently a normative MAY. (2) This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_121: *** 4968,4974 **** return a partial response using a status code of 200 (OK). If a cache receives a 5xx response while attempting to revalidate an ! entry, it may either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it MAY return a previously received response unless the cached entry includes the "must-revalidate" Cache-Control directive (see section 14.9). --- 4974,4980 ---- return a partial response using a status code of 200 (OK). If a cache receives a 5xx response while attempting to revalidate an ! entry, it MAY either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it MAY return a previously received response unless the cached entry includes the "must-revalidate" Cache-Control directive (see section 14.9). *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_122: *** 4979,4985 **** Unless the origin server explicitly prohibits the caching of their responses, the application of GET and HEAD methods to any resources SHOULD NOT have side effects that would lead to erroneous behavior if ! these responses are taken from a cache. They may still have side effects, but a cache is not required to consider such side effects in its caching decisions. Caches are always expected to observe an origin server's explicit restrictions on caching. --- 4985,4991 ---- Unless the origin server explicitly prohibits the caching of their responses, the application of GET and HEAD methods to any resources SHOULD NOT have side effects that would lead to erroneous behavior if ! these responses are taken from a cache. They MAY still have side effects, but a cache is not required to consider such side effects in its caching decisions. Caches are always expected to observe an origin server's explicit restrictions on caching. *************** Reason: This is apparently a normative MAY. --------------- ** issue MMS_AUDIT_ITEM_123: *** 4989,4995 **** "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URLs as fresh unless the server provides an explicit expiration time. This specifically means ! that responses from HTTP/1.0 servers for such URIs should not be taken from a cache. See section 9.1.1 for related information. --- 4995,5001 ---- "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URLs as fresh unless the server provides an explicit expiration time. This specifically means ! that responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache. See section 9.1.1 for related information. *************** Reason: This is apparently a normative SHOULD NOT. --------------- ** issue MMS_AUDIT_ITEM_124: *** 4996,5003 **** 13.10 Invalidation After Updates or Deletions The effect of certain methods performed on a resource at the origin ! server may cause one or more existing cache entries to become non- ! transparently invalid. That is, although they may continue to be "fresh," they do not accurately reflect what the origin server would return for a new request on that resource. --- 5002,5009 ---- 13.10 Invalidation After Updates or Deletions The effect of certain methods performed on a resource at the origin ! server might cause one or more existing cache entries to become non- ! transparently invalid. That is, although they might continue to be "fresh," they do not accurately reflect what the origin server would return for a new request on that resource. *************** Reason: (1) This "may" is not intended to be normative. (2) This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_125: *** 5007,5019 **** There is no way for the HTTP protocol to guarantee that all such cache entries are marked invalid. For example, the request that caused the ! change at the origin server may not have gone through the proxy where a cache entry is stored. However, several rules help reduce the likelihood of erroneous behavior. In this section, the phrase "invalidate an entity" means that the cache ! should either remove all instances of that entity from its storage, or ! should mark these as "invalid" and in need of a mandatory revalidation before they can be returned in response to a subsequent request. Some HTTP methods MUST cause a cache to invalidate an entity. This is --- 5013,5025 ---- There is no way for the HTTP protocol to guarantee that all such cache entries are marked invalid. For example, the request that caused the ! change at the origin server might not have gone through the proxy where a cache entry is stored. However, several rules help reduce the likelihood of erroneous behavior. In this section, the phrase "invalidate an entity" means that the cache ! SHOULD either remove all instances of that entity from its storage, or ! SHOULD mark these as "invalid" and in need of a mandatory revalidation before they can be returned in response to a subsequent request. Some HTTP methods MUST cause a cache to invalidate an entity. This is *************** Reason: (1) This "may" is not intended to be normative. (2) This is apparently a normative SHOULD. (3) This is apparently a normative SHOULD. --------------- ** issue MMS_AUDIT_ITEM_126: *** 5028,5039 **** if the host part is the same as in the Request-URI. A cache that passes through requests for methods it does not understand ! should invalidate any entities referred to by the Request-URI. 13.11 Write-Through Mandatory ! All methods that may be expected to cause modifications to the origin server's resources MUST be written through to the origin server. This currently includes all methods except for GET and HEAD. A cache MUST NOT reply to such a request from a client before having transmitted the --- 5034,5045 ---- if the host part is the same as in the Request-URI. A cache that passes through requests for methods it does not understand ! SHOULD invalidate any entities referred to by the Request-URI. 13.11 Write-Through Mandatory ! All methods that might be expected to cause modifications to the origin server's resources MUST be written through to the origin server. This currently includes all methods except for GET and HEAD. A cache MUST NOT reply to such a request from a client before having transmitted the *************** Reason: (1) This is apparently a normative SHOULD. (2) This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_127: *** 5053,5062 **** If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8) response is received from a resource while any existing responses for the same resource are cached, the cache SHOULD use the new response to ! reply to the current request. It may insert it into cache storage and ! may, if it meets all other requirements, use it to respond to any future requests that would previously have caused the old response to be ! returned. If it inserts the new response into cache storage it should follow the rules in section 13.5.3. Note: a new response that has an older Date header value than --- 5059,5068 ---- If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8) response is received from a resource while any existing responses for the same resource are cached, the cache SHOULD use the new response to ! reply to the current request. It MAY insert it into cache storage and ! MAY, if it meets all other requirements, use it to respond to any future requests that would previously have caused the old response to be ! returned. If it inserts the new response into cache storage it SHOULD follow the rules in section 13.5.3. Note: a new response that has an older Date header value than *************** Reason: (1) This is apparently a normative MAY. (2) This is apparently a normative MAY. (3) This is apparently a normative SHOULD. --------------- ** issue MMS_AUDIT_ITEM_128: *** 5079,5090 **** retrieved. By default, an expiration time does not apply to history mechanisms. If ! the entity is still in storage, a history mechanism should display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents. ! This should not be construed to prohibit the history mechanism from ! telling the user that a view may be stale. Note: if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors to --- 5085,5096 ---- retrieved. By default, an expiration time does not apply to history mechanisms. If ! the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents. ! This is not to be construed to prohibit the history mechanism from ! telling the user that a view might be stale. Note: if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors to *************** Reason: (1) This is apparently a normative SHOULD. (2) This "should" is not intended to be normative. (3) This "may" is not intended to be normative. --------------- ** issue MMS_AUDIT_ITEM_129: *** 5906,5912 **** 14.9.6 Cache Control Extensions The Cache-Control header field can be extended through the use of one or ! more cache-extension tokens, each with an optional assigned value. Informational extensions (those which do not require a change in cache behavior) may be added without changing the semantics of other directives. Behavioral extensions are designed to work by acting as --- 5912,5918 ---- 14.9.6 Cache Control Extensions The Cache-Control header field can be extended through the use of one or ! more cache-extension tokens, each of which might include an assigned value. Informational extensions (those which do not require a change in cache behavior) may be added without changing the semantics of other directives. Behavioral extensions are designed to work by acting as *************** Reason: Not all cache-extension token values will necessarily allow an assigned value. ---------------