HomeLoginHelp Factory

TEST GROUP INFO

Gist

Out of scope requirements

Warnings

This test group is documented but not implemented. See developer notes below for details.

Requirements

This test group tests the following 117 requirement(s).

  1. "HTTP/1.1 recipients MUST respect the charset label provided by the sender" (rfc2616)
  2. "and those user agents that have a provision to "guess" a charset MUST use the charset from the ... content-type field if they support that charset, rather than the recipient's preference, when initially displaying a document" (rfc2616)
  3. "Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include "chunked", unless the message is terminated by closing the connection" (rfc2616)
  4. "When the "chunked" transfer- coding is used, it MUST be the last transfer-coding applied to the message-body" (rfc2616)
  5. "An entity-body transferred via HTTP messages MUST be represented in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph" (rfc2616)
  6. "HTTP applications MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP" (rfc2616)
  7. "If an entity-body is encoded with a content-coding, the underlying data MUST be in a form defined above prior to being encoded" (rfc2616)
  8. "Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value" (rfc2616)
  9. "If an application receives an unrecognized multipart subtype, the application MUST treat it as being equivalent to "multipart/mixed"" (rfc2616)
  10. "HTTP/1.1 applications MUST NOT generate more than three digits after the decimal point" (rfc2616)
  11. "An entity tag MUST be unique across all versions of all entities associated with a particular resource" (rfc2616)
  12. "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" (rfc2616)
  13. "A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests" (rfc2616)
  14. "For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant" (rfc2616)
  15. "Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding" (rfc2616)
  16. "When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body" (rfc2616)
  17. "HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected" (rfc2616)
  18. "The absoluteURI form is REQUIRED when the request is being made to a proxy" (rfc2616)
  19. "To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies" (rfc2616)
  20. "In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field" (rfc2616)
  21. "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" (rfc2616)
  22. "An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity host names) MUST use the following rules for determining the requested resource on an HTTP/1.1 request" (rfc2616)
  23. "Any Host header field value in the request MUST be ignored" (rfc2616)
  24. "If the host as determined by rule 1 or 2 is not a valid host on the server, the response MUST be a 400 (Bad Request) error message" (rfc2616)
  25. "If a client will wait for a 100 (Continue) response before sending the request body, it MUST send an Expect request-header field (section 14.20) with the "100-continue" expectation" (rfc2616)
  26. "A client MUST NOT send an Expect request-header field (section 14.20) with the "100-continue" expectation if it does not intend to send a request body" (rfc2616)
  27. "Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server MUST either respond with 100 (Continue) status and continue to read from the input stream, or respond with a final status code" (rfc2616)
  28. "The origin server MUST NOT wait for the request body before sending the 100 (Continue) response" (rfc2616)
  29. "It MUST NOT perform the requested method if it returns a final status code" (rfc2616)
  30. "An origin server SHOULD NOT send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" expectation, and MUST NOT send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client" (rfc2616)
  31. "An origin server that sends a 100 (Continue) response MUST ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection prematurely" (rfc2616)
  32. "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" (rfc2616)
  33. "POST requests MUST obey the message transmission requirements set out in section 8.2" (rfc2616)
  34. "If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response" (rfc2616)
  35. "The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement" (rfc2616)
  36. "The recipient of the entity ... MUST return a 501 (Not Implemented) response in such cases" (rfc2616)
  37. "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 attempt to apply the request to some other resource" (rfc2616)
  38. "If the server desires that the request be applied to a different URI, ... it MUST send a 301 (Moved Permanently) response" (rfc2616)
  39. "PUT requests MUST obey the message transmission requirements set out in section 8.2" (rfc2616)
  40. "A TRACE request MUST NOT include an entity" (rfc2616)
  41. "The server MUST send a final response after the request has been completed" (rfc2616)
  42. "The origin server MUST create the resource before returning the 201 status code" (rfc2616)
  43. "The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields" (rfc2616)
  44. "The response MUST NOT include an entity" (rfc2616)
  45. "If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued" (rfc2616)
  46. "If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued" (rfc2616)
  47. "The requested resource MUST be accessed through the proxy given by the Location field" (rfc2616)
  48. "If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued" (rfc2616)
  49. "The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource" (rfc2616)
  50. "The response MUST include an Allow header containing a list of valid methods for the requested resource" (rfc2616)
  51. "The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource" (rfc2616)
  52. "It MUST NOT be generated by clients" (rfc2616)
  53. "Clients MUST NOT use weak validators in other forms of request" (rfc2616)
  54. "In order to be legal, a strong entity tag MUST change whenever the associated entity value changes in any way" (rfc2616)
  55. "If an entity tag has been provided by the origin server, MUST use that entity tag in any cache-conditional request (using If- Match or If-None-Match)" (rfc2616)
  56. "An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since or If-Unmodified-Since header field) and one or more entity tags (e.g., in an If-Match, If-None-Match, or If-Range header field) as cache validators, MUST NOT return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in the request" (rfc2616)
  57. "Content-Encoding - Content-Range - Content-Type A non-transparent proxy MAY modify or add these fields to a message that does not include no-transform, but if it does so, it MUST add a Warning 214 (Transformation applied) if one does not already appear in the message (see section 14.46)" (rfc2616)
  58. "If the choice is not made available, then the Accept-Language header field MUST NOT be given in the request" (rfc2616)
  59. "Although this is not recommended, user agents operating under severe connectivity constraints MAY violate this directive but, if so, MUST explicitly warn the user that an unvalidated response has been provided" (rfc2616)
  60. "The warning MUST be provided on each unvalidated access, and SHOULD require explicit user confirmation" (rfc2616)
  61. "If the content-coding of an entity is not "identity", then the response MUST include a Content-Encoding entity-header (section 14.11) that lists the non-identity content-coding(s) used" (rfc2616)
  62. "If multiple encodings have been applied to an entity, the content codings MUST be listed in the order in which they were applied" (rfc2616)
  63. "If the message is received with a transfer-encoding, that encoding MUST be removed prior to checking the Content-MD5 value against the received entity" (rfc2616)
  64. "Conversion of all line breaks to CRLF MUST NOT be done before computing or checking the digest" (rfc2616)
  65. "the line break convention used in the text actually transmitted MUST be left unaltered when computing the digest" (rfc2616)
  66. "The recipient of an invalid byte-content-range- spec MUST ignore it and any content transferred along with it" (rfc2616)
  67. "Origin servers MUST include a Date header field in all responses, except in these cases" (rfc2616)
  68. "A client without a clock MUST NOT send a Date header field in a request" (rfc2616)
  69. "An origin server without a clock MUST NOT assign Expires or Last- Modified values to a response, unless these values were associated with the resource by a system or user with a reliable clock" (rfc2616)
  70. "it MUST be in RFC 1123 date format" (rfc2616)
  71. "The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL" (rfc2616)
  72. "A client MUST include a Host header field in all HTTP/1.1 request messages" (rfc2616)
  73. "If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value" (rfc2616)
  74. "A request intended to update a resource (e.g., a PUT) MAY include an If-Match header field to signal that the request method MUST NOT be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource" (rfc2616)
  75. "An origin server MUST NOT send a Last-Modified date which is later than the server's time of message origination" (rfc2616)
  76. "In such cases, where the resource's last modification would indicate some time in the future, the server MUST replace that date with the message origination date" (rfc2616)
  77. "The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard" (rfc2616)
  78. "The URI MUST NOT include a fragment" (rfc2616)
  79. "Therefore, the keyword MUST be supplied within a Connection header field (section 14.10) whenever TE is present in an HTTP/1.1 message" (rfc2616)
  80. "Message header fields listed in the Trailer header field MUST NOT include the following header fields" (rfc2616)
  81. "If multiple encodings have been applied to an entity, the transfer- codings MUST be listed in the order in which they were applied" (rfc2616)
  82. "The server MUST use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched" (rfc2616)
  83. "The capabilities and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, although the first action after changing the protocol MUST be a response to the initial HTTP request containing the Upgrade header field" (rfc2616)
  84. "Therefore, the upgrade keyword MUST be supplied within a Connection header field (section 14.10) whenever Upgrade is present in an HTTP/1.1 message" (rfc2616)
  85. "If a character set other than ISO-8859-1 is used, it MUST be encoded in the warn-text using the method described in RFC 2047 [14]" (rfc2616)
  86. "A system receiving this warning MUST NOT take any automated action" (rfc2616)
  87. "214 Transformation applied MUST be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the Content-Encoding header) or media-type (as specified in the Content-Type header) of the response, or the entity-body of the response, unless this Warning code already appears in the response" (rfc2616)
  88. "If an implementation sends a message with one or more Warning headers whose version is HTTP/1.0 or lower, then the sender MUST include in each warning-value a warn-date that matches the date in the response" (rfc2616)
  89. "The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages" (rfc2616)
  90. "If an HTTP server translates HTTP URIs directly into file system calls, the server MUST take special care not to serve files that were not intended to be delivered to HTTP clients" (rfc2616)
  91. "On such a system, an HTTP server MUST disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to be accessible via the HTTP server" (rfc2616)
  92. "Similarly, files intended for reference only internally to the server (such as access control files, configuration files, and script code) MUST be protected from inappropriate retrieval, since they might contain sensitive information" (rfc2616)
  93. "If a single server supports multiple organizations that do not trust one another, then it MUST check the values of Location and Content- Location headers in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority" (rfc2616)
  94. "Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols MUST either change the value of the Content-Type header field or decode the entity-body before forwarding the message" (rfc2616)
  95. "Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client" (rfc2616)
  96. "Proxies/gateways MUST remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol" (rfc2616)
  97. "Servers MUST accept absolute URIs" (rfc2616)
  98. "Require that the origin server MUST NOT wait for the request body before it sends a required 100 (Continue) response" (rfc2616)
  99. "The meaning of "If-Match: *" is that the method SHOULD be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see section 14.44) exists, and MUST NOT be performed if the representation does not exist" (rfc2616)
  100. "ICAP clients MUST be able to handle all three types of responses" (rfc3507)
  101. "This MUST be an absolute URI that specifies both the complete hostname and the path of the resource being requested" (rfc3507)
  102. "Similar to HTTP, ICAP requests MUST start with a request line that contains a method, the complete URI of the ICAP resource being requested, and an ICAP version string" (rfc3507)
  103. "Host (REQUIRED in ICAP as it is in HTTP/1.1)" (rfc3507)
  104. "HTTP headers MUST start with the request-line or status-line for requests and responses, respectively, followed by interesting HTTP headers" (rfc3507)
  105. "The encapsulated headers MUST be terminated by a blank line, in order to make them human readable, and in order to terminate line-by-line HTTP parsers" (rfc3507)
  106. "Despite the above restrictions on encapsulation, the hop-by-hop Proxy-Authenticate and Proxy-Authorization headers MUST be forwarded to the ICAP server in the ICAP header section (not the encapsulated message)" (rfc3507)
  107. "To effect a Preview, an ICAP client MUST add a "Preview" (rfc3507)
  108. "The ICAP client MUST treat this the same as if it had sent the entire message to the ICAP server and an identical message was returned" (rfc3507)
  109. "If the entire encapsulated HTTP body did not fit in the preview, the ICAP client MUST send the remainder of its ICAP message, starting from the first chunk after the preview" (rfc3507)
  110. "In REQMOD mode, the ICAP request MUST contain an encapsulated HTTP request" (rfc3507)
  111. "The headers and body (if any) MUST both be encapsulated, except that hop-by-hop headers are not encapsulated" (rfc3507)
  112. "Using encapsulation described in Section 4.4, the header and body of the HTTP response to be modified MUST be included in the ICAP body" (rfc3507)
  113. "As with the other method, the hop-by-hop headers of the encapsulated messages MUST NOT be forwarded" (rfc3507)
  114. "The Encapsulated header MUST indicate the byte-offsets of the beginning of each of these four parts" (rfc3507)

Developer notes

These requirements are for classes of implementations that the current Co-Advisor code does not test (e.g., HTTP user agents or ICAP clients).

Members

This test group contains no members.

Memberships

This test group belongs to no groups.

Internal Identifier

This test group identifier is test_group/any/requirement-scope-not. Please use that identifier when refering to this test group.



© The Measurement FactoryCo-Advisor  ·  2.0.0b10terms  ·  privacy