--
Scott Lawrence
Consulting Engineer <lawrence@agranat.com>
Agranat Systems, Inc. Embedded Web Technology
http://www.agranat.com/
Due to some clumsiness on my part, some of these diffs got swapped;
I've corrected them by hand so that the upper half of each is the
version from the most recent draft, and the lower half is my suggested
change, with commentary in the format Jeff originated (thanks for
the
script, Jeff). The result is that they are ok for human use,
but
don't try to feed this to 'patch' or anything.
***************
** issue MMS_AUDIT_ITEM_130:
*** 5146,5152 ****
from being used with a media range,
such an event is believed to be
unlikely given the lack of any "q"
parameters in the IANA media
type registry and the rare usage
of any media type parameters in
! Accept. Future media types should be
discouraged from registering
any parameter named "q".
The example
--- 5146,5152 ----
from being used with a media range,
such an event is believed to be
unlikely given the lack of any "q"
parameters in the IANA media
type registry and the rare usage
of any media type parameters in
! Accept. Future media types are discouraged
from registering
any parameter named "q".
The example
***************
Reason:
Not a protocol requirement; changed to active voice.
---------------
** issue MMS_AUDIT_ITEM_131:
*** 5198,5207 ****
image/jpeg
= 0.5
text/html;level=2
= 0.4
text/html;level=3
= 0.7
! Note: A user agent may be provided with
a default set of quality
values for certain media ranges.
However, unless the user agent is
a closed system which cannot interact
with other rendering agents,
! this default set should be configurable
by the user.
14.2 Accept-Charset
--- 5198,5207 ----
image/jpeg
= 0.5
text/html;level=2
= 0.4
text/html;level=3
= 0.7
! Note: A user agent might be provided
with a default set of quality
values for certain media ranges.
However, unless the user agent is
a closed system which cannot interact
with other rendering agents,
! this default set aught to be configurable
by the user.
14.2 Accept-Charset
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_132:
*** 5215,5221 ****
Accept-Charset = "Accept-Charset"
":"
1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
! Character set values are described in section 3.4.
Each charset may be
given an associated quality value which represents
the user's preference
for that charset. The default value is q=1.
An example is
--- 5215,5221 ----
Accept-Charset = "Accept-Charset"
":"
1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
! Character set values are described in section 3.4.
Each charset MAY be
given an associated quality value which represents
the user's preference
for that charset. The default value is q=1.
An example is
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_133:
*** 5289,5304 ****
information that a different content-coding
is meaningful to the client.
Note: If the request does not include
an Accept-Encoding field, and
! if the "identity" content-coding is unavailable,
then preference
! should be given to content-codings commonly
understood by HTTP/1.0
! clients (i.e., "gzip" and "compress");
some older clients
! improperly display messages sent with
other content-encodings. The
! server may also make this decision based
on information about the
! particular user-agent or client.
Note: Most HTTP/1.0 applications
do not recognize or obey qvalues
! associated with content-codings. This
means that qvalues should
! never be sent with x-gzip or x-compress.
--- 5289,5304 ----
information that a different content-coding
is meaningful to the client.
Note: If the request does not include
an Accept-Encoding field, and
! if the "identity" content-coding is unavailable,
then it is
! advisable to give preference to content-codings
commonly
! understood by HTTP/1.0 clients (i.e.,
"gzip" and "compress"); some
! older clients improperly display messages
sent with other
! content-encodings. The server might also
make this decision based on
! information about the particular user-agent
or client.
Note: Most HTTP/1.0 applications
do not recognize or obey qvalues
! associated with content-codings. This
means that it will not work
! to send qvalues with x-gzip or x-compress.
***************
Reason:
Rephrased to avoid keywords; not normative; this is advice to
implementors on backward compatibility, not requirements for 1.1
---------------
** issue MMS_AUDIT_ITEM_134:
*** 5348,5354 ****
header is present, then all languages which
are assigned a quality
factor greater than 0 are acceptable.
! It may be contrary to the privacy expectations of
the user to send an
Accept-Language header with the complete linguistic
preferences of the
user in every request. For a discussion of this
issue, see section
15.1.4.
--- 5348,5354 ----
header is present, then all languages which
are assigned a quality
factor greater than 0 are acceptable.
! It might be contrary to the privacy expectations of
the user to send an
Accept-Language header with the complete linguistic
preferences of the
user in every request. For a discussion of this
issue, see section
15.1.4.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_135:
*** 5356,5369 ****
Note: As intelligibility is highly
dependent on the individual
user, it is recommended that client
applications make the choice of
linguistic preference available
to the user. If the choice is not
! made available, then the Accept-Language
header field must not be
given in the request.
Note: When making the choice of linguistic
preference available to
! the user, implementers should take into
account the fact that users
are not familiar with the details
of language matching as described
! above, and should provide appropriate
guidance. As an example,
! users may assume that on selecting "en-gb",
they will be served any
kind of English document if British
English is not available. A
--- 5356,5369 ----
Note: As intelligibility is highly
dependent on the individual
user, it is recommended that client
applications make the choice of
linguistic preference available
to the user. If the choice is not
! made available, then the Accept-Language
header field MUST NOT be
given in the request.
Note: When making the choice of linguistic
preference available to
! the user, implementers are advised to
take into account the fact that users
are not familiar with the details
of language matching as described
! above, and provide appropriate guidance.
As an example,
! users might assume that on selecting
"en-gb", they will be served any
kind of English document if British
English is not available. A
***************
Reason:
(1) Upcase keyword; normative.
(2) Rephrased to avoid keywords; not normative.
(3) Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_136:
*** 5371,5377 ****
INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998
! user agent may suggest in such a case
to add "en" to get the best
matching behavior.
--- 5371,5377 ----
INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998
! user agent could suggest in such a case
to add "en" to get the best
matching behavior.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_137:
*** 5444,5457 ****
header in the response giving the actual supported
methods.
A proxy MUST NOT modify the Allow header field
even if it does not
! understand all the methods specified, since the user
agent MAY have
other means of communicating with the origin
server.
14.8 Authorization
A user agent that wishes to authenticate itself
with a server--usually,
! but not necessarily, after receiving a 401 response--MAY
do so by
including an Authorization request-header field
with the request. The
Authorization field value consists of credentials
containing the
authentication information of the user agent
for the realm of the
--- 5444,5457 ----
header in the response giving the actual supported
methods.
A proxy MUST NOT modify the Allow header field
even if it does not
! understand all the methods specified, since the user
agent might have
other means of communicating with the origin
server.
14.8 Authorization
A user agent that wishes to authenticate itself
with a server--usually,
! but not necessarily, after receiving a 401 response--does
so by
including an Authorization request-header field
with the request. The
Authorization field value consists of credentials
containing the
authentication information of the user agent
for the realm of the
***************
Reason:
(1) Rephrased to avoid keywords; not normative.
(2) Rephrased to avoid keywords; not normative; Changed to active
voice
---------------
** issue MMS_AUDIT_ITEM_138:
*** 5461,5467 ****
HTTP access authentication is described in "HTTP
Authentication: Basic
and Digest Access Authentication" .. If a request
is authenticated and a
realm specified, the same credentials SHOULD
be valid for all other
! requests within this realm.
When a shared cache (see section 13.7) receives
a request containing an
Authorization field, it MUST NOT return the
corresponding response as a
--- 5461,5469 ----
HTTP access authentication is described in "HTTP
Authentication: Basic
and Digest Access Authentication" .. If a request
is authenticated and a
realm specified, the same credentials SHOULD
be valid for all other
! requests within this realm (assuming that the authentication
scheme
! itself does not require otherwise, such as credentials
that vary
! according to a challenge value or using syncronized
clocks).
When a shared cache (see section 13.7) receives
a request containing an
Authorization field, it MUST NOT return the
corresponding response as a
***************
Reason:
This isn't strictly an MMS change, but I think that it may clarify
the
intent; take it or leave it.
---------------
** issue MMS_AUDIT_ITEM_139:
*** 5485,5491 ****
authenticate the
new request.
3. If the response includes the "public"
Cache-Control directive, it
! may be returned in
reply to any subsequent request.
--- 5487,5493 ----
authenticate the
new request.
3. If the response includes the "public"
Cache-Control directive, it
! MAY be returned in
reply to any subsequent request.
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_140:
*** 5501,5514 ****
adversely interfering with the request or response.
These directives
typically override the default caching algorithms.
Cache directives are
unidirectional in that the presence of a directive
in a request does not
! imply that the same directive should be given in
the response.
! Note that HTTP/1.0 caches may not implement
Cache-Control and may
only implement Pragma: no-cache
(see section 14.32).
! Cache directives must be passed through by a proxy
or gateway
application, regardless of their significance
to that application, since
! the directives may be applicable to all recipients
along the
request/response chain. It is not possible to
specify a cache-directive
for a specific cache.
--- 5503,5516 ----
adversely interfering with the request or response.
These directives
typically override the default caching algorithms.
Cache directives are
unidirectional in that the presence of a directive
in a request does not
! imply that the same directive is to be given in the
response.
! Note that HTTP/1.0 caches might not implement
Cache-Control and might
only implement Pragma: no-cache
(see section 14.32).
! Cache directives MUST be passed through by a proxy
or gateway
application, regardless of their significance
to that application, since
! the directives might be applicable to all recipients
along the
request/response chain. It is not possible to
specify a cache-directive
for a specific cache.
***************
Reason:
(1) Rephrased to avoid keywords; not normative.
(2) Upcase keyword; normative.
(3) Rephrased to avoid keywords; not normative.
(4) Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_141:
*** 5542,5548 ****
directive appears with a 1#field-name parameter,
it applies only to the
named field or fields, and not to the rest of
the request or response.
This mechanism supports extensibility; implementations
of future
! versions of the HTTP protocol may apply these directives
to header
fields not defined in HTTP/1.1.
The cache-control directives can be broken down
into these general
--- 5544,5550 ----
directive appears with a 1#field-name parameter,
it applies only to the
named field or fields, and not to the rest of
the request or response.
This mechanism supports extensibility; implementations
of future
! versions of the HTTP protocol might apply these directives
to header
fields not defined in HTTP/1.1.
The cache-control directives can be broken down
into these general
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_142:
*** 5584,5590 ****
single user and MUST NOT be cached
by a shared cache. This allows an
origin server to state that the
specified parts of the response are
intended for only one user and are
not a valid response for requests
! by other users. A private (non-shared)
cache may cache the response.
Note: This usage of the word private
only controls where the
response may be cached, and cannot
ensure the privacy of the
--- 5586,5592 ----
single user and MUST NOT be cached
by a shared cache. This allows an
origin server to state that the
specified parts of the response are
intended for only one user and are
not a valid response for requests
! by other users. A private (non-shared)
cache MAY cache the response.
Note: This usage of the word private
only controls where the
response may be cached, and cannot
ensure the privacy of the
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_143:
*** 5620,5626 ****
no-store
The purpose of the no-store directive
is to prevent the inadvertent
release or retention of sensitive
information (for example, on backup
! tapes). The no-store directive applies
to the entire message, and may
be sent either in a response or
in a request. If sent in a request, a
cache MUST NOT store any part of
either this request or any response
to it. If sent in a response, a
cache MUST NOT store any part of
--- 5622,5628 ----
no-store
The purpose of the no-store directive
is to prevent the inadvertent
release or retention of sensitive
information (for example, on backup
! tapes). The no-store directive applies
to the entire message, and MAY
be sent either in a response or
in a request. If sent in a request, a
cache MUST NOT store any part of
either this request or any response
to it. If sent in a response, a
cache MUST NOT store any part of
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_144:
*** 5631,5655 ****
attempt to remove the information
from volatile storage as promptly
as possible after forwarding it.
! Even when this directive is associated
with a response, users may
explicitly store such a response
outside of the caching system (e.g.,
! with a "Save As" dialog). History buffers
may store such responses as
part of their normal operation.
The purpose of this directive is
to meet the stated requirements of
certain users and service authors
who are concerned about accidental
releases of information via unanticipated
accesses to cache data
! structures. While the use of this directive
may improve privacy in
some cases, we caution that it is
NOT in any way a reliable or
sufficient mechanism for ensuring
privacy. In particular, malicious
! or compromised caches may not recognize
or obey this directive; and
! communications networks may be vulnerable
to eavesdropping.
14.9.3 Modifications of the Basic Expiration Mechanism
! The expiration time of an entity may be specified
by the origin server
! using the Expires header (see section 14.20). Alternatively,
it may be
specified using the max-age directive in a response.
When the max-age
cache-control directive is present in a cached
response, the response is
stale if its current age is greater than the
age value given (in
--- 5633,5657 ----
attempt to remove the information
from volatile storage as promptly
as possible after forwarding it.
! Even when this directive is associated
with a response, users MAY
explicitly store such a response
outside of the caching system (e.g.,
! with a "Save As" dialog). History buffers
MAY store such responses as
part of their normal operation.
The purpose of this directive is
to meet the stated requirements of
certain users and service authors
who are concerned about accidental
releases of information via unanticipated
accesses to cache data
! structures. While the use of this directive
might improve privacy in
some cases, we caution that it is
NOT in any way a reliable or
sufficient mechanism for ensuring
privacy. In particular, malicious
! or compromised caches might not recognize
or obey this directive; and
! communications networks might be vulnerable
to eavesdropping.
14.9.3 Modifications of the Basic Expiration Mechanism
! The expiration time of an entity MAY be specified
by the origin server
! using the Expires header (see section 14.20). Alternatively,
it MAY be
specified using the max-age directive in a response.
When the max-age
cache-control directive is present in a cached
response, the response is
stale if its current age is greater than the
age value given (in
***************
Reason:
(1, 2)
Upcase keyword; normative (not sure that it
should be, but I
couldn't see a way to fix this without a rewrite
and I think we'd
rather avoid that particular firestorm).
(3)
Rephrased to avoid keywords; not normative.
(4) Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_145:
*** 5662,5668 ****
the max-age directive overrides the Expires
header, even if the Expires
header is more restrictive. This rule allows
an origin server to
provide, for a given response, a longer expiration
time to an HTTP/1.1
! (or later) cache than to an HTTP/1.0 cache. This
may be useful if
certain HTTP/1.0 caches improperly calculate
ages or expiration times,
perhaps due to desynchronized clocks.
--- 5664,5670 ----
the max-age directive overrides the Expires
header, even if the Expires
header is more restrictive. This rule allows
an origin server to
provide, for a given response, a longer expiration
time to an HTTP/1.1
! (or later) cache than to an HTTP/1.0 cache. This
might be useful if
certain HTTP/1.0 caches improperly calculate
ages or expiration times,
perhaps due to desynchronized clocks.
***************
Reason:
Rephrased to avoid keywords; not normative;
this is backward-compatibility advise to implementors, not a requirement
---------------
** issue MMS_AUDIT_ITEM_146:
*** 5701,5713 ****
Note: most older
caches, not compliant with this specification,
do not implement
any Cache-Control directives. An origin server
wishing to use
a Cache-Control directive that restricts, but
! does not prevent, caching
by an HTTP/1.1-compliant cache may
exploit the requirement
that the max-age directive overrides the
Expires header,
and the fact that pre-HTTP/1.1-compliant caches
do not observe
the max-age directive.
Other directives allow a user agent to modify
the basic expiration
! mechanism. These directives may be specified on a
request:
max-age
Indicates that the client is willing
to accept a response whose age
--- 5703,5715 ----
Note: most older
caches, not compliant with this specification,
do not implement
any Cache-Control directives. An origin server
wishing to use
a Cache-Control directive that restricts, but
! does not prevent, caching
by an HTTP/1.1-compliant cache MAY
exploit the requirement
that the max-age directive overrides the
Expires header,
and the fact that pre-HTTP/1.1-compliant caches
do not observe
the max-age directive.
Other directives allow a user agent to modify
the basic expiration
! mechanism. These directives MAY be specified on a
request:
max-age
Indicates that the client is willing
to accept a response whose age
***************
Reason:
(1, 2) Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_147:
*** 5740,5746 ****
the expiration time of a response, the cache
MUST attach a Warning
header to the stale response, using Warning
110 (Response is stale).
! Note: A cache may be configured to return
stale responses without
validation, but only if this does
not conflict with any MUST-level
requirements concerning cache validation
(e.g., a "must-revalidate"
Cache-Control directive).
--- 5742,5748 ----
the expiration time of a response, the cache
MUST attach a Warning
header to the stale response, using Warning
110 (Response is stale).
! Note: A cache MAY be configured to return
stale responses without
validation, but only if this does
not conflict with any MUST-level
requirements concerning cache validation
(e.g., a "must-revalidate"
Cache-Control directive).
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_148:
*** 5752,5758 ****
14.9.4 Cache Revalidation and Reload Controls
! Sometimes a user agent may want or need to insist
that a cache
revalidate its cache entry with the origin server
(and not just with the
next cache along the path to the origin server),
or to reload its cache
entry from the origin server. End-to-end revalidation
may be necessary
--- 5754,5760 ----
14.9.4 Cache Revalidation and Reload Controls
! Sometimes a user agent might want or need to insist
that a cache
revalidate its cache entry with the origin server
(and not just with the
next cache along the path to the origin server),
or to reload its cache
entry from the origin server. End-to-end revalidation
may be necessary
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_149:
*** 5760,5766 ****
expiration time of the cached response. End-to-end
reload may be
necessary if the cache entry has become corrupted
for some reason.
! End-to-end revalidation may be requested either when
the client does not
have its own local cached copy, in which case
we call it "unspecified
end-to-end revalidation", or when the client
does have a local cached
copy, in which case we call it "specific end-to-end
revalidation."
--- 5762,5768 ----
expiration time of the cached response. End-to-end
reload may be
necessary if the cache entry has become corrupted
for some reason.
! End-to-end revalidation might be requested either
when the client does not
have its own local cached copy, in which case
we call it "unspecified
end-to-end revalidation", or when the client
does have a local cached
copy, in which case we call it "specific end-to-end
revalidation."
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_150:
*** 5770,5777 ****
End-to-end reload
The request includes a "no-cache"
Cache-Control directive or, for
! compatibility with HTTP/1.0 clients,
"Pragma: no-cache". No field
! names may be included with the no-cache
directive in a request. The
server MUST NOT use a cached copy
when responding to such a
request.[jg178]
--- 5772,5779 ----
End-to-end reload
The request includes a "no-cache"
Cache-Control directive or, for
! compatibility with HTTP/1.0 clients,
"Pragma: no-cache". Field
! names MUST NOT be included with the no-cache
directive in a request. The
server MUST NOT use a cached copy
when responding to such a
request.[jg178]
***************
Reason:
Rephrased to use MUST NOT instead of 'No xxx may' to clarify - the
construction in the draft isn't as clear in its use of the keywords.
---------------
** issue MMS_AUDIT_ITEM_151:
*** 5799,5822 ****
INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998
directive, to revalidate its own
cache entry, and the client has
! supplied its own validator in the request,
the supplied validator may
differ from the validator currently
stored with the cache entry. In
! this case, the cache may use either validator
in making its own
request without affecting semantic
transparency.
! However, the choice of validator may affect
performance. The best
approach is for the intermediate
cache to use its own validator when
making its request. If the server
replies with 304 (Not Modified),
! then the cache should return its now
validated copy to the client
with a 200 (OK) response. If the
server replies with a new entity and
! cache validator, however, the intermediate
cache should compare the
returned validator with the one
provided in the client's request,
using the strong comparison function.
If the client's validator is
equal to the origin server's, then
the intermediate cache simply
returns 304 (Not Modified). Otherwise,
it returns the new entity with
a 200 (OK) response.
! If a request includes the no-cache directive,
it should not include
min-fresh, max-stale, or max-age.
only-if-cached
--- 5801,5824 ----
INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998
directive, to revalidate its own
cache entry, and the client has
! supplied its own validator in the request,
the supplied validator might
differ from the validator currently
stored with the cache entry. In
! this case, the cache MAY use either validator
in making its own
request without affecting semantic
transparency.
! However, the choice of validator might
affect performance. The best
approach is for the intermediate
cache to use its own validator when
making its request. If the server
replies with 304 (Not Modified),
! then the cache can return its now validated
copy to the client
with a 200 (OK) response. If the
server replies with a new entity and
! cache validator, however, the intermediate
cache can compare the
returned validator with the one
provided in the client's request,
using the strong comparison function.
If the client's validator is
equal to the origin server's, then
the intermediate cache simply
returns 304 (Not Modified). Otherwise,
it returns the new entity with
a 200 (OK) response.
! If a request includes the no-cache directive,
it SHOULD NOT include
min-fresh, max-stale, or max-age.
only-if-cached
***************
Reason:
(1, 2, 3, 4) Rephrased to avoid keywords; not normative; these are
advice to implementors, not requirements.
---------------
** issue MMS_AUDIT_ITEM_152:
*** 5832,5846 ****
forwarded within that group of caches.
must-revalidate
! Because a cache may be configured to
ignore a server's specified
! expiration time, and because a client
request may include a max-stale
directive (which has a similar effect),
the protocol also includes a
mechanism for the origin server
to require revalidation of a cache
entry on any subsequent use. When
the must-revalidate directive is
present in a response received by
a cache, that cache MUST NOT use
the entry after it becomes stale
to respond to a subsequent request
without first revalidating it with
the origin server. (I.e., the
! cache must do an end-to-end revalidation
every time, if, based solely
on the origin server's Expires or
max-age value, the cached response
is stale.)
--- 5834,5848 ----
forwarded within that group of caches.
must-revalidate
! Because a cache MAY be configured to
ignore a server's specified
! expiration time, and because a client
request MAY include a max-stale
directive (which has a similar effect),
the protocol also includes a
mechanism for the origin server
to require revalidation of a cache
entry on any subsequent use. When
the must-revalidate directive is
present in a response received by
a cache, that cache MUST NOT use
the entry after it becomes stale
to respond to a subsequent request
without first revalidating it with
the origin server. (I.e., the
! cache MUST do an end-to-end revalidation
every time, if, based solely
on the origin server's Expires or
max-age value, the cached response
is stale.)
***************
Reason:
Upcase keywords; normative.
---------------
** issue MMS_AUDIT_ITEM_153:
*** 5850,5856 ****
particular, if the cache cannot
reach the origin server for any
reason, it MUST generate a 504 (Gateway
Timeout) response.
! Servers should send the must-revalidate
directive if and only if
failure to revalidate a request
on the entity could result in
incorrect operation, such as a silently
unexecuted financial
transaction. Recipients MUST NOT
take any automated action that
--- 5852,5858 ----
particular, if the cache cannot
reach the origin server for any
reason, it MUST generate a 504 (Gateway
Timeout) response.
! Servers SHOULD send the must-revalidate
directive if and only if
failure to revalidate a request
on the entity could result in
incorrect operation, such as a silently
unexecuted financial
transaction. Recipients MUST NOT
take any automated action that
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_154:
*** 5863,5869 ****
unvalidated copy of the entity if
revalidation fails.
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. The warning MUST be provided
on each unvalidated access,
and SHOULD require explicit user
confirmation.
--- 5865,5871 ----
unvalidated copy of the entity if
revalidation fails.
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. The warning MUST be provided
on each unvalidated access,
and SHOULD require explicit user
confirmation.
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_155:
*** 5899,5905 ****
Therefore, if a message includes
the no-transform directive, an
intermediate cache or proxy MUST
NOT change those headers that are
listed in section 13.5.2 as being
subject to the no-transform
! directive. This implies that the cache
or proxy must not change any
aspect of the entity-body that is
specified by these headers.
--- 5901,5907 ----
Therefore, if a message includes
the no-transform directive, an
intermediate cache or proxy MUST
NOT change those headers that are
listed in section 13.5.2 as being
subject to the no-transform
! directive. This implies that the cache
or proxy MUST NOT change any
aspect of the entity-body that is
specified by these headers.
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_156:
*** 5908,5914 ****
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
modifiers to the existing base of cache directives.
Both the new
directive and the standard directive are supplied,
such that
--- 5910,5916 ----
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
modifiers to the existing base of cache directives.
Both the new
directive and the standard directive are supplied,
such that
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_157:
*** 5935,5941 ****
any cache which is shared only by members of
the community named within
its value may cache the response. An origin
server wishing to allow the
UCI community to use an otherwise private response
in their shared
! cache(s) may do so by including
Cache-Control:
private, community="UCI"
A cache seeing this header field will act correctly
even if the cache
--- 5937,5943 ----
any cache which is shared only by members of
the community named within
its value may cache the response. An origin
server wishing to allow the
UCI community to use an otherwise private response
in their shared
! cache(s) could do so by including
Cache-Control:
private, community="UCI"
A cache seeing this header field will act correctly
even if the cache
***************
Reason:
Rephrased to avoid keywords; not normative; this is advice, not
a
requirement
---------------
** issue MMS_AUDIT_ITEM_158:
*** 5982,5988 ****
INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998
in either the request or the response header
fields indicates that the
! connection should not be considered `persistent'
(section 8.1) after the
current request/response is complete.
HTTP/1.1 applications that do not support persistent
connections MUST
--- 5984,5990 ----
INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998
in either the request or the response header
fields indicates that the
! connection SHOULD NOT be considered `persistent'
(section 8.1) after the
current request/response is complete.
HTTP/1.1 applications that do not support persistent
connections MUST
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_159:
*** 6034,6040 ****
The Content-Language entity-header field describes
the natural
language(s) of the intended audience for the
enclosed entity. Note that
! this may not be equivalent to all the languages used
within the entity-
body.
--- 6036,6042 ----
The Content-Language entity-header field describes
the natural
language(s) of the intended audience for the
enclosed entity. Note that
! this might not be equivalent to all the languages
used within the entity-
body.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_160:
*** 6051,6057 ****
Content-Language:
da
If no Content-Language is specified, the default
is that the content is
! intended for all language audiences. This may mean
that the sender does
not consider it to be specific to any natural
language, or that the
sender does not know for which language it is
intended.
--- 6053,6059 ----
Content-Language:
da
If no Content-Language is specified, the default
is that the content is
! intended for all language audiences. This might mean
that the sender does
not consider it to be specific to any natural
language, or that the
sender does not know for which language it is
intended.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_161:
*** 6065,6073 ****
does not mean that it is intended for multiple
linguistic audiences. An
example would be a beginner's language primer,
such as "A First Lesson
in Latin," which is clearly intended to be used
by an English-literate
! audience. In this case, the Content-Language should
only include "en".
! Content-Language may be applied to any media type
-- it is not limited
to textual documents.
--- 6067,6075 ----
does not mean that it is intended for multiple
linguistic audiences. An
example would be a beginner's language primer,
such as "A First Lesson
in Latin," which is clearly intended to be used
by an English-literate
! audience. In this case, the Content-Language would
properly only include "en".
! Content-Language MAY be applied to any media type
-- it is not limited
to textual documents.
***************
Reason:
(1) Rephrased to avoid keywords; not normative.
(2) Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_162:
*** 6149,6155 ****
Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
! The Content-MD5 header field may be generated by
an origin server to
function as an integrity check of the entity-body.
Only origin servers
may generate the Content-MD5 header field; proxies
and gateways MUST NOT
generate it, as this would defeat its value
as an end-to-end integrity
--- 6151,6157 ----
Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
! The Content-MD5 header field MAY be generated by
an origin server to
function as an integrity check of the entity-body.
Only origin servers
may generate the Content-MD5 header field; proxies
and gateways MUST NOT
generate it, as this would defeat its value
as an end-to-end integrity
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_163:
*** 6164,6170 ****
INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998
! any Transfer-Encoding that may have been applied to
the message-body. 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.
--- 6166,6172 ----
INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998
! any Transfer-Encoding applied to the message-body.
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.
***************
Reason:
Rephrased to clarify the use of the keywords and upcase the MUST
---------------
** issue MMS_AUDIT_ITEM_164:
*** 6179,6185 ****
paragraph.
Note: There are several consequences
of this. The entity-body for
! composite types may contain many body-parts,
each with its own MIME
and HTTP headers (including Content-MD5,
Content-Transfer-Encoding,
and Content-Encoding headers). If
a body-part has a Content-
Transfer-Encoding or Content-Encoding
header, it is assumed that
--- 6181,6187 ----
paragraph.
Note: There are several consequences
of this. The entity-body for
! composite types MAY contain many body-parts,
each with its own MIME
and HTTP headers (including Content-MD5,
Content-Transfer-Encoding,
and Content-Encoding headers). If
a body-part has a Content-
Transfer-Encoding or Content-Encoding
header, it is assumed that
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_165:
*** 6199,6207 ****
digest is the transmission byte
order defined for the type. Lastly,
HTTP allows transmission of text
types with any of several line
break conventions and not just the
canonical form using CRLF.
! Conversion of all line breaks to CRLF
should not be done before
computing or checking the digest:
the line break convention used in
! the text actually transmitted should
be left unaltered when
computing the digest.
--- 6201,6209 ----
digest is the transmission byte
order defined for the type. Lastly,
HTTP allows transmission of text
types with any of several line
break conventions and not just the
canonical form using CRLF.
! Conversion of all line breaks to CRLF
MUST NOT be done before
computing or checking the digest:
the line break convention used in
! the text actually transmitted MUST be
left unaltered when
computing the digest.
***************
Reason:
I actually changed 'should' to MUST here in two places - if it is
not
always done as specified here, it will not interoperate.
---------------
** issue MMS_AUDIT_ITEM_166:
*** 6209,6215 ****
The Content-Range entity-header is sent with
a partial entity-body to
specify where in the full entity-body the partial
body should be
! inserted. It SHOULD indicate the total length of
the full entity-body,
unless this length is unknown or difficult to
determine.
Content-Range
= "Content-Range" ":" content-range-spec
--- 6211,6217 ----
The Content-Range entity-header is sent with
a partial entity-body to
specify where in the full entity-body the partial
body should be
! inserted **. It SHOULD indicate the total length
of the full entity-body,
unless this length is unknown or difficult to
determine.
Content-Range
= "Content-Range" ":" content-range-spec
***************
Reason:
I flagged this one just to make a comment - the use of 'inserted'
here
is not really the general way to describe this, but I couldn't
think
of a better one without rewriting the whole paragraph. Since
I'm not
actually convinced that range requests are generally usefull I
didn't
take that on.
---------------
** issue MMS_AUDIT_ITEM_167:
*** 6229,6236 ****
The asterisk "*" character means that the instance-length
is unknown at
the time when the response was generated.
! Unlike byte-ranges-specifier values, a byte-range-resp-spec
may only
! specify one range, and must contain absolute byte
positions for both the
first and last byte of the range.
A byte-content-range-spec with a byte-range-resp-spec
whose last-byte-
--- 6231,6238 ----
The asterisk "*" character means that the instance-length
is unknown at
the time when the response was generated.
! Unlike byte-ranges-specifier values, a byte-range-resp-spec
MUST only
! specify one range, and MUST contain absolute byte
positions for both the
first and last byte of the range.
A byte-content-range-spec with a byte-range-resp-spec
whose last-byte-
***************
Reason:
Rephrased to use MUST rather than may; this seemed the intent to
me,
and upcase the keywords.
---------------
** issue MMS_AUDIT_ITEM_168:
*** 6278,6284 ****
multipart/byteranges media type. A reponse
to a request for multiple
ranges, whose result is a single range, MAY
be sent as a
multipart/byteranges media type with one part.
A client that cannot
! decode a multipart/byteranges message should not
ask for multiple byte-
ranges in a single request.
--- 6280,6286 ----
multipart/byteranges media type. A reponse
to a request for multiple
ranges, whose result is a single range, MAY
be sent as a
multipart/byteranges media type with one part.
A client that cannot
! decode a multipart/byteranges message SHOULD NOT
ask for multiple byte-
ranges in a single request.
***************
Reason:
Upcase keyword; normative
<aside>
this would be stupid anyway - I don't really think this sort of
obvious stuff should even be in here, but... - SL
</aside>
---------------
** issue MMS_AUDIT_ITEM_169:
*** 6290,6296 ****
SHOULD return them in the order that they appeared
in the request.
If the server ignores a byte-range-spec because
it is syntactically
! invalid, the server should treat the request as if
the invalid Range
header field did not exist. (Normally, this
means return a 200 response
containing the full entity).
--- 6292,6298 ----
SHOULD return them in the order that they appeared
in the request.
If the server ignores a byte-range-spec because
it is syntactically
! invalid, the server SHOULD treat the request as if
the invalid Range
header field did not exist. (Normally, this
means return a 200 response
containing the full entity).
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_170:
*** 6377,6383 ****
14.18.1 Clockless Origin Server Operation
! Some origin server implementations may not have a
clock available. 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. It MAY assign an
--- 6379,6385 ----
14.18.1 Clockless Origin Server Operation
! Some origin server implementations might not have
a clock available. 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. It MAY assign an
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_171:
*** 6390,6396 ****
The ETag response-header field provides the current
value of the entity
tag for the requested variant. The headers used
with entity tags are
! described in sections 14.24, 14.26 and 14.44. The
entity tag may be used
for comparison with other entities from the
same resource (see section
13.3.3).
--- 6392,6398 ----
The ETag response-header field provides the current
value of the entity
tag for the requested variant. The headers used
with entity tags are
! described in sections 14.24, 14.26 and 14.44. The
entity tag MAY be used
for comparison with other entities from the
same resource (see section
13.3.3).
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_172:
*** 6460,6466 ****
servers.
Note: Because of the presence of
older implementations, the
! protocol allows ambiguous situations
in which a client may send
"Expect: 100-continue" without receiving
either a 417 (Expectation
Failed) status or a 100 (Continue)
status. Therefore, when a client
sends this header field to an origin
server (possibly via a proxy)
--- 6462,6468 ----
servers.
Note: Because of the presence of
older implementations, the
! protocol allows ambiguous situations
in which a client MAY send
"Expect: 100-continue" without receiving
either a 417 (Expectation
Failed) status or a 100 (Continue)
status. Therefore, when a client
sends this header field to an origin
server (possibly via a proxy)
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_173:
*** 6470,6483 ****
INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998
from which it has never seen a 100
(Continue) status, the client
! should not wait for an indefinite or
lengthy period before sending
the request body.
14.21 Expires
The Expires entity-header field gives the date/time
after which the
! response should be considered stale. A stale cache
entry may not
normally be returned by a cache (either a proxy
cache or a user agent
cache) unless it is first validated with the
origin server (or with an
intermediate cache that has a fresh copy of
the entity). See section
--- 6472,6485 ----
INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998
from which it has never seen a 100
(Continue) status, the client
! need not wait for an indefinite or lengthy
period before sending
the request body.
14.21 Expires
The Expires entity-header field gives the date/time
after which the
! response is to be considered stale. A stale cache
entry MUST NOT
normally be returned by a cache (either a proxy
cache or a user agent
cache) unless it is first validated with the
origin server (or with an
intermediate cache that has a fresh copy of
the entity). See section
***************
Reason:
(1) Rephrased to avoid keywords; not normative; this is advice,
not a requirement.
(2) Rephrased to avoid MAY; perhaps I should have used SHOULD
though... the 'normally' confuses the intent,
I think
---------------
** issue MMS_AUDIT_ITEM_174:
*** 6500,6512 ****
especially including the value "0", as in the
past (i.e., "already
expired").
! To mark a response as "already expired," an origin
server should use an
Expires date that is equal to the Date header
value. (See the rules for
expiration calculations in section 13.2.4.)
! To mark a response as "never expires," an origin server
should use an
Expires date approximately one year from the
time the response is sent.
! HTTP/1.1 servers should not send Expires dates more
than one year in the
future.
The presence of an Expires header field with
a date value of some time
--- 6502,6514 ----
especially including the value "0", as in the
past (i.e., "already
expired").
! To mark a response as "already expired," an origin
server sends an
Expires date that is equal to the Date header
value. (See the rules for
expiration calculations in section 13.2.4.)
! To mark a response as "never expires," an origin server
sends an
Expires date approximately one year from the
time the response is sent.
! HTTP/1.1 servers SHOULD NOT send Expires dates more
than one year in the
future.
The presence of an Expires header field with
a date value of some time
***************
Reason:
These are explanatory; rephrased to avoid the keyword 'should'.
---------------
** issue MMS_AUDIT_ITEM_175:
*** 6545,6551 ****
passed through a proxy the original issuer's
address SHOULD be used.
Note: The client SHOULD NOT send
the From header field without the
! user's approval, as it may conflict with
the user's privacy
interests or their site's security
policy. It is strongly
recommended that the user be able
to disable, enable, and modify
the value of this field at any time
prior to a request.
--- 6547,6553 ----
passed through a proxy the original issuer's
address SHOULD be used.
Note: The client SHOULD NOT send
the From header field without the
! user's approval, as it might conflict
with the user's privacy
interests or their site's security
policy. It is strongly
recommended that the user be able
to disable, enable, and modify
the value of this field at any time
prior to a request.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_176:
*** 6565,6572 ****
Host
= "Host" ":" host [ ":" port ] ; Section 3.2.2
A "host" without any trailing port information
implies the default port
for the service requested (e.g., "80" for an
HTTP URL). For example, a
! request on the origin server for <http://www.w3.org/pub/WWW/>
MUST
! include:
GET
/pub/WWW/ HTTP/1.1
Host:
www.w3.org
--- 6567,6574 ----
Host
= "Host" ":" host [ ":" port ] ; Section 3.2.2
A "host" without any trailing port information
implies the default port
for the service requested (e.g., "80" for an
HTTP URL). For example, a
! request on the origin server for <http://www.w3.org/pub/WWW/>
would
! properly include:
GET
/pub/WWW/ HTTP/1.1
Host:
www.w3.org
***************
Reason:
This requirement is stated elsewhere, so I rephrased the example
to
get rid of the MUST.
---------------
** issue MMS_AUDIT_ITEM_177:
*** 6682,6694 ****
If-Modified-Since; see section 14.35
for full details.
Note that If-Modified-Since times
are interpreted by the server,
! whose clock may not be synchronized with
the client.
Note: When handling an If-Modified-Since
header field, some servers
will use an exact date comparison
function, rather than a less-than
function, for deciding whether to
send a 304 (Not Modified)
response. To get best results when
sending an If-Modified-Since
! header field for cache validation, clients
should use the exact
date string received in a previous
Last-Modified header field
whenever possible.
--- 6684,6696 ----
If-Modified-Since; see section 14.35
for full details.
Note that If-Modified-Since times
are interpreted by the server,
! whose clock might not be synchronized
with the client.
Note: When handling an If-Modified-Since
header field, some servers
will use an exact date comparison
function, rather than a less-than
function, for deciding whether to
send a 304 (Not Modified)
response. To get best results when
sending an If-Modified-Since
! header field for cache validation, clients
are advised to use the exact
date string received in a previous
Last-Modified header field
whenever possible.
***************
Reason:
(1, 2) Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_178:
*** 6776,6782 ****
cache, possibly using the Vary mechanism, see
section 14.44) exists, and
SHOULD be performed if the representation does
not exist. This feature
! may be useful in preventing races between PUT operations.
Examples:
--- 6778,6784 ----
cache, possibly using the Vary mechanism, see
section 14.44) exists, and
SHOULD be performed if the representation does
not exist. This feature
! is intended to be useful in preventing races between
PUT operations.
Examples:
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_179:
*** 6806,6815 ****
If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
If the client has no entity tag for an entity,
but does have a Last-
! Modified date, it may use that date in a If-Range
header. (The server
can distinguish between a valid HTTP-date and
any form of entity-tag by
! examining no more than two characters.) The If-Range
header should only
! be used together with a Range header, and must be
ignored if the request
does not include a Range header, or if the server
does not support the
sub-range operation.
--- 6808,6817 ----
If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
If the client has no entity tag for an entity,
but does have a Last-
! Modified date, it MAY use that date in a If-Range
header. (The server
can distinguish between a valid HTTP-date and
any form of entity-tag by
! examining no more than two characters.) The If-Range
header SHOULD only
! be used together with a Range header, and MUST be
ignored if the request
does not include a Range header, or if the server
does not support the
sub-range operation.
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_180:
*** 6824,6830 ****
The If-Unmodified-Since request-header field
is used with a method to
make it conditional. If the requested resource
has not been modified
! since the time specified in this field, the server
should perform the
requested operation as if the If-Unmodified-Since
header were not
present.
--- 6826,6832 ----
The If-Unmodified-Since request-header field
is used with a method to
make it conditional. If the requested resource
has not been modified
! since the time specified in this field, the server
SHOULD perform the
requested operation as if the If-Unmodified-Since
header were not
present.
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_181:
*** 6846,6852 ****
If the request normally (i.e., without the If-Unmodified-Since
header)
would result in anything other than a 2xx or
412 status, the If-
! Unmodified-Since header should be ignored.
If the specified date is invalid, the header is ignored.
--- 6848,6854 ----
If the request normally (i.e., without the If-Unmodified-Since
header)
would result in anything other than a 2xx or
412 status, the If-
! Unmodified-Since header SHOULD be ignored.
If the specified date is invalid, the header is ignored.
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_182:
*** 6872,6883 ****
be the last-update time stamp of the record.
For virtual objects, it may
be the last time the internal state changed.
An origin server MUST NOT send a Last-Modified
date which is later than
the server's time of message origination. 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.
! An origin server should obtain the Last-Modified value
of the entity as
close as possible to the time that it generates
the Date value of its
response. This allows a recipient to make an
accurate assessment of the
entity's modification time, especially if the
entity changes near the
--- 6874,6888 ----
be the last-update time stamp of the record.
For virtual objects, it may
be the last time the internal state changed.
An origin server MUST NOT send a Last-Modified
date which is later than
the server's time of message origination. 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.
! An origin server SHOULD obtain the Last-Modified value
of the entity as
close as possible to the time that it generates
the Date value of its
response. This allows a recipient to make an
accurate assessment of the
entity's modification time, especially if the
entity changes near the
***************
Reason:
Upcase keyword; normative.
The 'may's in the preceding paragraph seem to me to be descriptive,
not normative, so I left them lower case.
---------------
** issue MMS_AUDIT_ITEM_183:
*** 6915,6921 ****
14.31 Max-Forwards
! The Max-Forwards request-header field MAY be used
with the TRACE
(section 14.31) and OPTIONS (section 9.2) methods
to limit the number of
proxies or gateways that can forward the request
to the next inbound
server. This can be useful when the client is
attempting to trace a
--- 6920,6926 ----
14.31 Max-Forwards
! The Max-Forwards request-header field provides a mechanism
with the TRACE
(section 14.31) and OPTIONS (section 9.2) methods
to limit the number of
proxies or gateways that can forward the request
to the next inbound
server. This can be useful when the client is
attempting to trace a
***************
Reason:
Removed keyword - the sentence is descriptive, not normative
---------------
** issue MMS_AUDIT_ITEM_184:
*** 6926,6932 ****
number of times this request message is to be
forwarded.
Each proxy or gateway recipient of a TRACE or
OPTIONS request containing
! a Max-Forwards header field SHOULD check and update
its value prior to
forwarding the request. If the received value
is zero (0), the recipient
MUST NOT forward the request; instead, it MUST
respond as the final
recipient. If the received Max-Forwards value
is greater than zero, then
--- 6931,6937 ----
number of times this request message is to be
forwarded.
Each proxy or gateway recipient of a TRACE or
OPTIONS request containing
! a Max-Forwards header field SHOULD check and update
its value prior to
forwarding the request. If the received value
is zero (0), the recipient
MUST NOT forward the request; instead, it MUST
respond as the final
recipient. If the received Max-Forwards value
is greater than zero, then
***************
Reason:
I marked this one because I think it should be a MUST where that
SHOULD is.
---------------
** issue MMS_AUDIT_ITEM_185:
--- 6946,6952 ----
14.32 Pragma
The Pragma general-header field is used to include
implementation-
! specific directives that may apply to any recipient
along the
request/response chain. All pragma directives
specify optional behavior
from the viewpoint of the protocol; however,
some systems MAY require
that behavior be consistent with the directives.
*** 6941,6947 ****
14.32 Pragma
The Pragma general-header field is used to include
implementation-
! specific directives that might apply to any recipient
along the
request/response chain. All pragma directives
specify optional behavior
from the viewpoint of the protocol; however,
some systems MAY require
that behavior be consistent with the directives.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_186:
--- 6969,6975 ----
Pragma directives MUST be passed through by a
proxy or gateway
application, regardless of their significance
to that application, since
! the directives may be applicable to all recipients
along the
request/response chain. It is not possible to
specify a pragma for a
specific recipient; however, any pragma directive
not relevant to a
recipient SHOULD be ignored by that recipient.
*** 6964,6970 ****
Pragma directives MUST be passed through by a
proxy or gateway
application, regardless of their significance
to that application, since
! the directives might be applicable to all recipients
along the
request/response chain. It is not possible to
specify a pragma for a
specific recipient; however, any pragma directive
not relevant to a
recipient SHOULD be ignored by that recipient.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_187:
--- 6991,6997 ----
Authentication: Basic and Digest Access Authentication"
. Unlike WWW-
Authenticate, the Proxy-Authenticate header
field applies only to the
current connection and SHOULD NOT be passed
on to downstream clients.
! However, an intermediate proxy may need to obtain
its own credentials by
requesting them from the downstream client,
which in some circumstances
will appear as if the proxy is forwarding the
Proxy-Authenticate header
field.
*** 6986,6992 ****
Authentication: Basic and Digest Access Authentication"
. Unlike WWW-
Authenticate, the Proxy-Authenticate header
field applies only to the
current connection and SHOULD NOT be passed
on to downstream clients.
! However, an intermediate proxy might need to obtain
its own credentials by
requesting them from the downstream client,
which in some circumstances
will appear as if the proxy is forwarding the
Proxy-Authenticate header
field.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_188:
--- 7036,7042 ----
Byte range specifications in HTTP apply to the
sequence of bytes in the
entity-body (not necessarily the same as the
message-body).
! A byte range operation may specify a single range
of bytes, or a set of
ranges within a single entity.
ranges-specifier
= byte-ranges-specifier
*** 7031,7037 ****
Byte range specifications in HTTP apply to the
sequence of bytes in the
entity-body (not necessarily the same as the
message-body).
! A byte range operation MAY specify a single range
of bytes, or a set of
ranges within a single entity.
ranges-specifier
= byte-ranges-specifier
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_189:
--- 7050,7056 ----
of the last byte in the range; that is, the
byte positions specified are
inclusive. Byte offsets start at zero.
! If the last-byte-pos value is present, it must be
greater than or equal
to the first-byte-pos in that byte-range-spec,
or the byte-range-spec is
syntactically invalid. The recipient of a byte-range-set
that includes
one or more syntactically invalid byte-range-spec
values MUST ignore the
*** 7045,7051 ****
of the last byte in the range; that is, the
byte positions specified are
inclusive. Byte offsets start at zero.
! If the last-byte-pos value is present, it MUST be
greater than or equal
to the first-byte-pos in that byte-range-spec,
or the byte-range-spec is
syntactically invalid. The recipient of a byte-range-set
that includes
one or more syntactically invalid byte-range-spec
values MUST ignore the
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_190:
--- 7108,7120 ----
14.35.2 Range Retrieval Requests
HTTP retrieval requests using conditional or
unconditional GET methods
! may request one or more sub-ranges of the entity,
instead of the entire
entity, using the Range request header, which
applies to the entity
returned as the result of the request:
Range = "Range"
":" ranges-specifier
A server MAY ignore the Range header. However,
HTTP/1.1 origin servers
! and intermediate caches should support byte ranges
when possible, since
Range supports efficient recovery from partially
failed transfers, and
supports efficient partial retrieval of large
entities.
*** 7103,7115 ****
14.35.2 Range Retrieval Requests
HTTP retrieval requests using conditional or
unconditional GET methods
! MAY request one or more sub-ranges of the entity,
instead of the entire
entity, using the Range request header, which
applies to the entity
returned as the result of the request:
Range = "Range"
":" ranges-specifier
A server MAY ignore the Range header. However,
HTTP/1.1 origin servers
! and intermediate caches SHOULD support byte ranges
when possible, since
Range supports efficient recovery from partially
failed transfers, and
supports efficient partial retrieval of large
entities.
***************
Reason:
(1, 2) Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_191:
--- 7131,7137 ----
if the GET is
otherwise successful and the condition is true. It
does not affect
the 304 (Not Modified) response returned if the
conditional is
false.
! In some cases, it may be more appropriate to use
the If-Range header
(see section 14.27) in addition to the Range
header.
If a proxy that supports ranges receives a Range
request, forwards the
*** 7126,7132 ****
if the GET is
otherwise successful and the condition is true. It
does not affect
the 304 (Not Modified) response returned if the
conditional is
false.
! In some cases, it might be more appropriate to use
the If-Range header
(see section 14.27) in addition to the Range
header.
If a proxy that supports ranges receives a Range
request, forwards the
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_192:
--- 7172,7178 ----
Unavailable) response to indicate how long the
service is expected to be
unavailable to the requesting client. This field
MAY also be used with
any 3xx (Redirection) response to indicate the
minimum time the user-
! agent should wait before issuing the redirected request.
The value of
this field can be either an HTTP-date or an
integer number of seconds
(in decimal) after the time of the response.
*** 7167,7173 ****
Unavailable) response to indicate how long the
service is expected to be
unavailable to the requesting client. This field
MAY also be used with
any 3xx (Redirection) response to indicate the
minimum time the user-
! agent is asked to wait before issuing the redirected
request. The value of
this field can be either an HTTP-date or an
integer number of seconds
(in decimal) after the time of the response.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_193:
--- 7206,7212 ----
INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998
! Note: Revealing the specific software
version of the server may
allow the server machine to become
more vulnerable to attacks
against software that is known to
contain security holes. Server
implementers are encouraged to make
this field a configurable
*** 7201,7207 ****
INTERNET-DRAFT HTTP/1.1 Friday, March 13, 1998
! Note: Revealing the specific software
version of the server might
allow the server machine to become
more vulnerable to attacks
against software that is known to
contain security holes. Server
implementers are encouraged to make
this field a configurable
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_194:
--- 7402,7408 ----
14.44 Vary
The Vary field value indicates the set of request-header
fields that
! fully determines, while the response is fresh, whether
a cache may use
the response to reply to a subsequent request
without revalidation. For
uncachable or stale responses, the Vary field
value advises the user
agent about the criteria that were used to select
the representation. A
*** 7397,7404 ****
14.44 Vary
The Vary field value indicates the set of request-header
fields that
! fully determines, while the response is fresh, whether
a cache is
! permitted to use
the response to reply to a subsequent request
without revalidation. For
uncachable or stale responses, the Vary field
value advises the user
agent about the criteria that were used to select
the representation. A
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_195:
--- 7523,7529 ----
14.46 Warning
The Warning response-header field is used to
carry additional
! information about the status of a response which
may not be reflected by
the response status code. This information is
typically, though not
exclusively, used to warn about a possible lack
of semantic transparency
from caching operations.
*** 7519,7525 ****
14.46 Warning
The Warning response-header field is used to
carry additional
! information about the status of a response which
might not be reflected by
the response status code. This information is
typically, though not
exclusively, used to warn about a possible lack
of semantic transparency
from caching operations.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_196:
--- 7540,7550 ----
; the Warning header, for use in debugging
warn-text
= quoted-string
warn-date
= <"> HTTP-date <">
! A response may carry more than one Warning header.
! The warn-text should be in a natural language and
character set that is
most likely to be intelligible to the human
user receiving the response.
! This decision may be based on any available knowledge,
such as the
location of the cache or user, the Accept-Language
field in a request,
the Content-Language field in a response, etc.
The default language is
English and the default character set is ISO-8859-1.
*** 7536,7546 ****
; the Warning header, for use in debugging
warn-text
= quoted-string
warn-date
= <"> HTTP-date <">
! A response MAY carry more than one Warning header.
! The warn-text SHOULD be in a natural language and
character set that is
most likely to be intelligible to the human
user receiving the response.
! This decision MAY be based on any available knowledge,
such as the
location of the cache or user, the Accept-Language
field in a request,
the Content-Language field in a response, etc.
The default language is
English and the default character set is ISO-8859-1.
***************
Reason:
(1, 2, 3) Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_197:
--- 7552,7559 ----
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].
! Any server or cache may add Warning headers to a response.
New Warning
! headers should be added after any existing Warning
headers. A cache MUST
NOT delete any Warning header that it received
with a response. However,
if a cache successfully validates a cache entry,
it SHOULD remove any
Warning headers previously attached to that
entry except as specified
*** 7548,7555 ****
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].
! Any server or cache MAY add Warning headers to a response.
New Warning
! headers SHOULD be added after any existing Warning
headers. A cache MUST
NOT delete any Warning header that it received
with a response. However,
if a cache successfully validates a cache entry,
it SHOULD remove any
Warning headers previously attached to that
entry except as specified
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_198:
--- 7564,7570 ----
When multiple Warning headers are attached to
a response, the user agent
SHOULD display as many of them as possible,
in the order that they
appear in the response. If it is not possible
to display all of the
! warnings, the user agent should follow these heuristics:
*** 7560,7566 ****
When multiple Warning headers are attached to
a response, the user agent
SHOULD display as many of them as possible,
in the order that they
appear in the response. If it is not possible
to display all of the
! warnings, the user agent SHOULD follow these heuristics:
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_199:
--- 7577,7583 ----
. Warnings in the user's preferred
character set take priority over
warnings in other
character sets but with identical warn-codes and
warn-agents.
! Systems that generate multiple Warning headers should
order them with
this user agent behavior in mind.
The warn-code consists of three digits. The first
digit indicates
*** 7573,7579 ****
. Warnings in the user's preferred
character set take priority over
warnings in other
character sets but with identical warn-codes and
warn-agents.
! Systems that generate multiple Warning headers SHOULD
order them with
this user agent behavior in mind.
The warn-code consists of three digits. The first
digit indicates
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_200:
--- 7612,7618 ----
24 hours.
199 Miscellaneous warning
! The warning text may include arbitrary
information to be presented to
a human user, or logged. A system
receiving this warning MUST NOT
take any automated action, besides
presenting the warning to the
user.
*** 7608,7614 ****
24 hours.
199 Miscellaneous warning
! The warning text MAY include arbitrary
information to be presented to
a human user, or logged. A system
receiving this warning MUST NOT
take any automated action, besides
presenting the warning to the
user.
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_201:
--- 7625,7631 ----
appears in the response.
299 Miscellaneous persistent warning
! The warning text may include arbitrary
information to be presented to
a human user, or logged. A system
receiving this warning MUST NOT
take any automated action.
*** 7621,7627 ****
appears in the response.
299 Miscellaneous persistent warning
! The warning text MAY include arbitrary
information to be presented to
a human user, or logged. A system
receiving this warning MUST NOT
take any automated action.
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_202:
--- 7657,7666 ----
WWW-Authenticate
= "WWW-Authenticate" ":" 1#challenge
The HTTP access authentication process is described
in "HTTP
Authentication: Basic and Digest Access Authentication"
. User agents
! MUST take special care in parsing the WWW-Authenticate
field value if it
! contains more than one challenge, or if more than
one WWW-Authenticate
! header field is provided, since the contents of a
challenge may itself
! contain a comma-separated list of authentication
parameters.
15 Security Considerations
*** 7653,7663 ****
WWW-Authenticate
= "WWW-Authenticate" ":" 1#challenge
The HTTP access authentication process is described
in "HTTP
Authentication: Basic and Digest Access Authentication"
. User agents
! are advised to take special care in parsing the WWW-Authenticate
field
! value as it might contain more than one challenge,
or if more than
! one WWW-Authenticate header field is provided, since
the contents of
! a challenge itself can contain a comma-separated
list of
! authentication parameters.
15 Security Considerations
***************
Reason:
Rephrased to avoid keywords; this is advice.
---------------
** issue MMS_AUDIT_ITEM_203:
--- 7697,7705 ----
15.1.1 Abuse of Server Log Information
A server is in the position to save personal
data about a user's
! requests which may identify their reading patterns
or subjects of
interest. This information is clearly confidential
in nature and its
! handling may be constrained by law in certain countries.
People using
the HTTP protocol to provide data are responsible
for ensuring that such
material is not distributed without the permission
of any individuals
that are identifiable by the published results.
*** 7694,7702 ****
15.1.1 Abuse of Server Log Information
A server is in the position to save personal
data about a user's
! requests which might identify their reading patterns
or subjects of
interest. This information is clearly confidential
in nature and its
! handling can be constrained by law in certain countries.
People using
the HTTP protocol to provide data are responsible
for ensuring that such
material is not distributed without the permission
of any individuals
that are identifiable by the published results.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_204:
--- 7715,7721 ----
possible to the provider of that information.
Four header fields are
worth special mention in this context: Server,
Via, Referer and From.
! Revealing the specific software version of the server
may allow the
server machine to become more vulnerable to
attacks against software
that is known to contain security holes. Implementers
SHOULD make the
Server header field a configurable option.
*** 7712,7718 ****
possible to the provider of that information.
Four header fields are
worth special mention in this context: Server,
Via, Referer and From.
! Revealing the specific software version of the server
might allow the
server machine to become more vulnerable to
attacks against software
that is known to contain security holes. Implementers
SHOULD make the
Server header field a configurable option.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_205:
--- 7730,7736 ----
links drawn. Although it can be very useful,
its power can be abused if
user details are not separated from the information
contained in the
Referer. Even when the personal information
has been removed, the
! Referer field may indicate a private document's URI
whose publication
would be inappropriate.
The information sent in the From field might
conflict with the user's
*** 7727,7733 ****
links drawn. Although it can be very useful,
its power can be abused if
user details are not separated from the information
contained in the
Referer. Even when the personal information
has been removed, the
! Referer field might indicate a private document's
URI whose publication
would be inappropriate.
The information sent in the From field might
conflict with the user's
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_206:
--- 7747,7753 ----
15.1.3 Encoding Sensitive Information in URL's
! Because the source of a link may be private information
or may reveal an
otherwise private information source, it is
strongly recommended that
the user be able to select whether or not the
Referer field is sent. For
*** 7744,7750 ****
15.1.3 Encoding Sensitive Information in URL's
! Because the source of a link might be private information
or may reveal an
otherwise private information source, it is
strongly recommended that
the user be able to select whether or not the
Referer field is sent. For
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_207:
--- 7765,7771 ----
Authors of services which use the HTTP protocol
SHOULD NOT use GET based
forms for the submission of sensitive data,
because this will cause this
data to be encoded in the request-URI. Many
existing servers, proxies,
! and user agents will log the request URI in some
place where it may be
visible to third parties. Servers can use POST-based
form submission
instead
*** 7762,7768 ****
Authors of services which use the HTTP protocol
SHOULD NOT use GET based
forms for the submission of sensitive data,
because this will cause this
data to be encoded in the request-URI. Many
existing servers, proxies,
! and user agents will log the request URI in some
place where it might be
visible to third parties. Servers can use POST-based
form submission
instead
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_208:
--- 7784,7790 ----
An approach that limits the loss of privacy would
be for a user agent to
omit the sending of Accept-Language headers
by default, and to ask the
! user whether it should start sending Accept-Language
headers to a server
if it detects, by looking for any Vary response-header
fields generated
by the server, that such sending could improve
the quality of service.
*** 7781,7787 ****
An approach that limits the loss of privacy would
be for a user agent to
omit the sending of Accept-Language headers
by default, and to ask the
! user whether or not to start sending Accept-Language
headers to a server
if it detects, by looking for any Vary response-header
fields generated
by the server, that such sending could improve
the quality of service.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_209:
--- 7797,7806 ----
users not behind a proxy, the network address
of the host running the
user agent will also serve as a long-lived user
identifier. In
environments where proxies are used to enhance
privacy, user agents
! should be conservative in offering accept header
configuration options
to end users. As an extreme privacy measure,
proxies could filter the
accept headers in relayed requests. General
purpose user agents which
! provide a high degree of header configurability should
warn users about
the loss of privacy which can be involved.
*** 7794,7803 ****
users not behind a proxy, the network address
of the host running the
user agent will also serve as a long-lived user
identifier. In
environments where proxies are used to enhance
privacy, user agents
! SHOULD be conservative in offering accept header
configuration options
to end users. As an extreme privacy measure,
proxies could filter the
accept headers in relayed requests. General
purpose user agents which
! provide a high degree of header configurability SHOULD
warn users about
the loss of privacy which can be involved.
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_210:
--- 7840,7846 ----
confirmation of an IP number/DNS name association,
rather than caching
the result of previous host name lookups. Many
platforms already can
cache host name lookups locally when appropriate,
and they SHOULD be
! configured to do so. These lookups should be cached,
however, only when
the TTL (Time To Live) information reported
by the name server makes it
likely that the cached information will remain
useful.
*** 7837,7844 ****
confirmation of an IP number/DNS name association,
rather than caching
the result of previous host name lookups. Many
platforms already can
cache host name lookups locally when appropriate,
and they SHOULD be
! configured to do so. It is proper for these
lookups to be cached,
! however, only when
the TTL (Time To Live) information reported
by the name server makes it
likely that the cached information will remain
useful.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_211:
--- 7863,7869 ----
15.4 Location Headers and Spoofing
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.
*** 7861,7867 ****
15.4 Location Headers and Spoofing
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.
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_212:
--- 7896,7902 ----
application's security model include but are
not limited to:
. Clients which have been idle for an extended
period following which
! the server may wish to cause the client
to reprompt the user for
credentials.
. Applications which include a session termination
indication (such as
*** 7894,7900 ****
application's security model include but are
not limited to:
. Clients which have been idle for an extended
period following which
! the server might wish to cause the client
to reprompt the user for
credentials.
. Applications which include a session termination
indication (such as
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_213:
--- 7915,7921 ----
15.7 Proxies and Caching
! By their very nature, HTTP proxies are men-in-the-middle,
and may
represent an opportunity for man-in-the-middle
attacks. Compromise of
the systems on which the proxies run can result
in serious security and
privacy problems. Proxies have access to security-related
information,
*** 7913,7919 ****
15.7 Proxies and Caching
! By their very nature, HTTP proxies are men-in-the-middle,
and
represent an opportunity for man-in-the-middle
attacks. Compromise of
the systems on which the proxies run can result
in serious security and
privacy problems. Proxies have access to security-related
information,
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_214:
--- 7941,7947 ----
Caching proxies provide additional potential
vulnerabilities, since the
contents of the cache represent an attractive
target for malicious
exploitation. Because cache contents persist
after an HTTP request is
! complete, an attack on the cache may reveal information
long after a
user believes that the information has been
removed from the network.
Therefore, cache contents should be protected
as sensitive information.
*** 7939,7945 ****
Caching proxies provide additional potential
vulnerabilities, since the
contents of the cache represent an attractive
target for malicious
exploitation. Because cache contents persist
after an HTTP request is
! complete, an attack on the cache might reveal information
long after a
user believes that the information has been
removed from the network.
Therefore, cache contents should be protected
as sensitive information.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_215:
--- 8443,8449 ----
However, we recommend that applications, when
parsing such headers,
recognize a single LF as a line terminator and
ignore the leading CR.
! The character set of an entity-body should be labeled
as the lowest
common denominator of the character codes used
within that body, with
the exception that not labeling the entity is
preferred over labeling
the entity with the labels US-ASCII or ISO-8859-1.
See section 3.7.1 and
*** 8441,8447 ****
However, we recommend that applications, when
parsing such headers,
recognize a single LF as a line terminator and
ignore the leading CR.
! The character set of an entity-body SHOULD be labeled
as the lowest
common denominator of the character codes used
within that body, with
the exception that not labeling the entity is
preferred over labeling
the entity with the labels US-ASCII or ISO-8859-1.
See section 3.7.1 and
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_216:
--- 8452,8469 ----
Additional rules for requirements on parsing
and encoding of dates and
other potential problems with date encodings
include:
! . HTTP/1.1 clients and caches should
assume that an RFC-850 date
which appears
to be more than 50 years in the future is in fact in
the past (this
helps solve the "year 2000" problem).
! . 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.
! . All expiration-related calculations
must be done in GMT. The local
time zone MUST
NOT influence the calculation or comparison of an
age or expiration
time.
. 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.
19.4 Differences Between HTTP Entities and RFC
2045 Entities
*** 8450,8467 ****
Additional rules for requirements on parsing
and encoding of dates and
other potential problems with date encodings
include:
! . HTTP/1.1 clients and caches SHOULD
assume that an RFC-850 date
which appears
to be more than 50 years in the future is in fact in
the past (this
helps solve the "year 2000" problem).
! . 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.
! . All expiration-related calculations
MUST be done in GMT. The local
time zone MUST
NOT influence the calculation or comparison of an
age or expiration
time.
. 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.
19.4 Differences Between HTTP Entities and RFC
2045 Entities
***************
Reason:
Upcase keyword; normative.
Actually, all this about how implementations MUST be done internally
is, I think, improper - all that matters is whether or not they
get it
right on the wire... (I don't disagree that these are good ways
to get
it right, just with whether or not the spec should say anything
about
how an implementation is done beyond its external behaviour).
---------------
** issue MMS_AUDIT_ITEM_217:
--- 8488,8500 ----
INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998
necessary. Proxies and gateways from MIME environments
to HTTP also need
! to be aware of the differences because some conversions
may be required.
19.4.1 MIME-Version
HTTP is not a MIME-compliant protocol (see appendix
19.4). However,
! HTTP/1.1 messages may include a single MIME-Version
general-header field
to indicate what version of the MIME protocol
was used to construct the
message. Use of the MIME-Version header field
indicates that the message
is in full compliance with the MIME protocol
(as defined in RFC
*** 8486,8498 ****
INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998
necessary. Proxies and gateways from MIME environments
to HTTP also need
! to be aware of the differences because some conversions
might be required.
19.4.1 MIME-Version
HTTP is not a MIME-compliant protocol (see appendix
19.4). However,
! HTTP/1.1 messages MAY include a single MIME-Version
general-header field
to indicate what version of the MIME protocol
was used to construct the
message. Use of the MIME-Version header field
indicates that the message
is in full compliance with the MIME protocol
(as defined in RFC
***************
Reason:
(1) Rephrased to avoid keywords; not normative.
(2) Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_218:
--- 8522,8528 ----
Where it is possible, a proxy or gateway from
HTTP to a strict RFC 2045
environment SHOULD translate all line breaks
within the text media types
described in section 3.7.1 of this document
to the RFC 2045 canonical
! form of CRLF. Note, however, that this may be complicated
by the
presence of a Content-Encoding and by the fact
that HTTP allows the use
of some character sets which do not use octets
13 and 10 to represent CR
and LF, as is the case for some multi-byte character
sets.
*** 8520,8526 ****
Where it is possible, a proxy or gateway from
HTTP to a strict RFC 2045
environment SHOULD translate all line breaks
within the text media types
described in section 3.7.1 of this document
to the RFC 2045 canonical
! form of CRLF. Note, however, that this might be complicated
by the
presence of a Content-Encoding and by the fact
that HTTP allows the use
of some character sets which do not use octets
13 and 10 to represent CR
and LF, as is the case for some multi-byte character
sets.
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_219:
--- 8612,8623 ----
19.4.7 MHTML and Line Length Limitations
HTTP implementations which share code with MHTML
[45] implementations
! should be aware of MIME line length limitations.
Since HTTP does not
have this limitation, HTTP does not fold long
lines. MHTML messages
being transported by HTTP follow all conventions
of MHTML, including
line length limitations and folding, canonicalization,
etc., since HTTP
transports all message-bodies as payload (see
section 3.7.2) and does
! not interpret the content or any MIME header lines
that may be contained
therein.
*** 8610,8621 ****
19.4.7 MHTML and Line Length Limitations
HTTP implementations which share code with MHTML
[45] implementations
! SHOULD be aware of MIME line length limitations.
Since HTTP does not
have this limitation, HTTP does not fold long
lines. MHTML messages
being transported by HTTP follow all conventions
of MHTML, including
line length limitations and folding, canonicalization,
etc., since HTTP
transports all message-bodies as payload (see
section 3.7.2) and does
! not interpret the content or any MIME header lines
that might be contained
therein.
***************
Reason:
(1) Upcase keyword; normative.
(2) Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_220:
--- 8625,8631 ----
RFC 1945 and RFC 2068 document protocol elements
used by some existing
HTTP implementations, but not consistently and
correctly across most
! HTTP/1.1 applications. Implementers should be aware
of these features,
but cannot rely upon their presence in, or interoperability
with, other
HTTP/1.1 applications. Some of these describe
proposed experimental
features, and some describe features that experimental
deployment found
*** 8623,8629 ****
RFC 1945 and RFC 2068 document protocol elements
used by some existing
HTTP implementations, but not consistently and
correctly across most
! HTTP/1.1 applications. Implementers are advised to
be aware of these features,
but cannot rely upon their presence in, or interoperability
with, other
HTTP/1.1 applications. Some of these describe
proposed experimental
features, and some describe features that experimental
deployment found
***************
Reason:
Rephrased to avoid keywords; not normative.
---------------
** issue MMS_AUDIT_ITEM_221:
--- 8652,8663 ----
An example is
Content-Disposition: attachment; filename="fname.ext"
! The receiving user agent should not respect any directory
path
! information that may seem to be present in the filename-parm
parameter,
which is the only parameter believed to apply
to HTTP implementations at
! this time. The filename should be treated as a terminal
component only.
! The implied suggestion is that the user agent should
not display the
response, but directly enter a `save response
as...' dialog.
See section 15.5 for Content-Disposition security
issues.
*** 8650,8661 ****
An example is
Content-Disposition: attachment; filename="fname.ext"
! The receiving user agent SHOULD NOT respect any directory
path
! information present in the filename-parm parameter,
which is the only parameter believed to apply
to HTTP implementations at
! this time. The filename SHOULD be treated as a terminal
component only.
! The implied suggestion is that the user agent SHOULD
NOT display the
response, but directly enter a `save response
as...' dialog.
See section 15.5 for Content-Disposition security
issues.
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_222:
--- 8749,8755 ----
. Both clients and servers MUST support the Host request-header.
! . A client that sends an HTTP/1.1 request must send a Host header.
. Servers MUST report a 400
(Bad Request) error if an HTTP/1.1
request does not
include a Host request-header.
*** 8747,8753 ****
. Both clients and servers MUST support the Host request-header.
! . A client that sends an HTTP/1.1 request MUST send a Host header.
. Servers MUST report a 400
(Bad Request) error if an HTTP/1.1
request does not
include a Host request-header.
***************
Reason:
Upcase keyword; normative.
---------------
** issue MMS_AUDIT_ITEM_223:
--- 8758,8766 ----
19.6.2 Compatibility with HTTP/1.0 Persistent Connections
! Some clients and servers may wish to be compatible
with some previous
implementations of persistent connections in
HTTP/1.0 clients and
! servers. Persistent connections in HTTP/1.0 must
be explicitly
negotiated as they are not the default behavior.
HTTP/1.0 experimental
implementations of persistent connections are
faulty, and the new
facilities in HTTP/1.1 are designed to rectify
these problems. The
*** 8756,8764 ****
19.6.2 Compatibility with HTTP/1.0 Persistent Connections
! Some clients and servers might wish to be compatible
with some previous
implementations of persistent connections in
HTTP/1.0 clients and
! servers. Persistent connections in HTTP/1.0 are explicitly
negotiated as they are not the default behavior.
HTTP/1.0 experimental
implementations of persistent connections are
faulty, and the new
facilities in HTTP/1.1 are designed to rectify
these problems. The
***************
Reason:
Rephrased to avoid keywords; not normative.