Gist
Not testable requirements
Warnings
This test group is documented but not implemented. See developer notes below for details.
Requirements
This test group tests the following 27 requirement(s).
- "The "chunked" transfer-coding MUST NOT be applied more
than once to a message-body" (rfc2616)
- "The proxy/gateway's response to that request MUST be in
the same major version as the request" (rfc2616)
- "If a proxy receives
a fully qualified domain name, the proxy MUST NOT change the host
name" (rfc2616)
- "They MUST NOT be
used for advertising or other non-essential information" (rfc2616)
- "Transfer-Encoding MUST be used to indicate any transfer-codings
applied by an application to ensure safe and proper transfer of the
message" (rfc2616)
- "Once a close
has been signaled, the client MUST NOT send any more requests on that
connection" (rfc2616)
- "The proxy server MUST signal persistent connections separately with
its clients and the origin servers (or other proxy servers) that it
connects to" (rfc2616)
- "A proxy server MUST NOT establish a HTTP/1.1 persistent connection
with an HTTP/1.0 client (but see RFC 2068 [33] for information and
discussion of the problems with the Keep-Alive header implemented by
many HTTP/1.0 clients)" (rfc2616)
- "If the body was preceded by a Content-Length header, the client MUST
close the connection" (rfc2616)
- "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" (rfc2616)
- "305 responses MUST only be generated by origin servers" (rfc2616)
- "Servers MUST NOT depend on clients being able to choose
deterministically between responses generated during the same second,
if their expiration times overlap" (rfc2616)
- "A transparent proxy MUST
preserve the entity-length (section 7.2.2) of the entity-body,
although it MAY change the transfer-length (section 4.4)" (rfc2616)
- "Message headers listed in the Connection header MUST NOT include
end-to-end headers, such as Cache-Control" (rfc2616)
- "HTTP/1.1 applications that do not support persistent connections MUST
include the "close" connection option in every message" (rfc2616)
- "proxies and gateways MUST NOT generate it, as this would defeat its
value as an end-to-end integrity check" (rfc2616)
- "A response with status code 206 (Partial
Content) MUST NOT include a Content-Range field with a byte-range-
resp-spec of "*"" (rfc2616)
- "The Proxy-Authenticate response-header field MUST be included as part
of a 407 (Proxy Authentication Required) response" (rfc2616)
- "The "*" value MUST NOT be generated by a proxy server" (rfc2616)
- "Applications MUST NOT combine entries which
have different received-protocol values" (rfc2616)
- "The user MUST be able
to set the contents of this field within a user preference or
application defaults configuration" (rfc2616)
- "An HTTP/1.1 implementation MAY internally represent a parsed
Expires date as earlier than the proper value, but MUST NOT
internally represent a parsed Expires date as later than the
proper value" (rfc2616)
- "A client that sends an HTTP/1.1 request MUST send a Host header" (rfc2616)
- "The Content-Length header field MUST NOT be sent
if these two lengths are different (i.e., if a Transfer-Encoding ... header field is present)" (rfc2616)
- "If an HTTP header incorrectly carries a date value with a time
zone other than GMT, it MUST be converted into GMT using the
most conservative possible conversion" (rfc2616)
- "This means that clients, servers, and proxies MUST be able to recover
from asynchronous close events" (rfc2616)
- "If HTTP clients cache the results of host name lookups in order to
achieve a performance improvement, they MUST observe the TTL
information reported by DNS" (rfc2616)
Developer notes
We believe these requirements cannot be tested in practice.
Common reasons include vague or undefined words (e.g., "MUST respect")
and actions generally not visible to a black-box test suite (e.g.,
"MUST ignore").
Sometimes it is simply not possible to force the device under test
to get into a desired (possibly buggy) state although that does not
mean the state is unreachable.
Note that some requirements are testable outside of the current
Co-Advisor scope (e.g., a requirement may be testable for end-clients
but not for proxies).
Members
This test group contains the following 2 members:
Memberships
This test group belongs to no groups.
Internal Identifier
This test group identifier is test_group/any/requirement-testable-not. Please use that identifier when refering to this test group.