- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 24 Jun 2012 12:18:32 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
P1, 2.1: Note: The term 'user agent' covers both those situations where there is a user (human) interacting with the software agent (and for which user interface or interactive suggestions might be made, e.g., warning the user or given the user an option in the case of security or privacy options) and also those where the software agent may act autonomously. "may" -> "can" P1, 8.2: HTTP log information is confidential in nature; its handling is often constrained by laws and regulations. Log information needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within individual entries helps, but is generally not sufficient to prevent real log traces from being re-identified based on correlation with other access characteristics. As such, access traces that are keyed to a specific client should not be published even if the key is pseudonymous. "should not" -> "SHOULD NOT" To minimize the risk of theft or accidental publication, log information should be purged of personally identifiable information, including user identifiers, IP addresses, and user-provided query parameters, as soon as that information is no longer necessary to support operational needs for security, auditing, or fraud control. "should" -> "SHOULD P2, 2.2.1: New method definitions need to indicate whether they are safe (Section 2.1.1), what semantics (if any) the request body has, and whether they are idempotent (Section 2.1.2). They also need to state whether they can be cached ([Part6]); in particular what conditions a missing "under"? cache may store the response, and under what conditions such a stored response may be used to satisfy a subsequent request. "may" -> "MAY" P2, 2.3.8: Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server MAY be sent immediately after the request (before a response is received). The usual caveats also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding. "may" -> "might" (twice) P2, 3.1: o Whether the header field should be preserved across redirects. "should" -> "ought to" P2, 4.5.4: The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy the original request, a user agent SHOULD perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which may itself be redirected further, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the effective request URI. "may" -> "can" P4, 2.4: HTTP/1.0 clients and caches might ignore entity-tags. Generally, last-modified values received or used by these systems will support transparent and efficient caching, and so HTTP/1.1 origin servers still ought to provide Last-Modified values. In those rare cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem, then HTTP/1.1 origin servers should not provide one. (see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/363) P6, 2.3.3: If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache can forward it to the requesting client without adding a new Warning (but without removing any existing Warning header fields). A cache shouldn't attempt to validate a response simply because that response became stale in transit. "shouldn't" -> "SHOULD NOT" P6, 2.4: Additionally, a cache can add an If-None-Match header field whose value is that of the ETag header field(s) from all responses stored for the requested URI, if present. However, if any of the stored responses contains only partial content, the cache shouldn't include its entity-tag in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored response. "shouldn't" -> "SHOULD NOT" P6, 3.2.3: For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive. We define this new directive to mean that, in addition to any private cache, any cache that 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 "may" -> "can" Feedback appreciated, Julian
Received on Sunday, 24 June 2012 10:19:02 UTC