RE: Intent of 14.38 Server

I'd be happy to do that, if someone else works out the canonicalization
rules (or restricts the set of modifications that can be made to, e.g.,
LWS tweaks).

As I recall, the number of different ways of saying the same thing is
really large -- e.g., not just LWS, but escapes, different list orders,
etc.

And, as a practical matter, no clients canonicalize. 

-----Original Message-----
From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]
On Behalf Of David Morris
Sent: Thursday, December 21, 2006 10:46 AM
To: Travis Snoozy (Volt)
Cc: ietf-http-wg@w3.org
Subject: RE: Intent of 14.38 Server



I recall the authentication dicussion Paul referenced, but not the
details. Given the conflicts noted below, and good engineering practice,
would be to normalize any values before using them in computing an hash
used as part of authentiction. That would allow LWS cleanup of any
header with no negative impact. Don't know what the digest auth rfc
requires however.

Dave Morris

On Thu, 21 Dec 2006, Travis Snoozy (Volt) wrote:

>
>
> Henrik Nordstrom said:
> <snip>
>
> > Is it really true that proxies is not allowed to clean up LWS in 
> > Server headers? I have always considered folding/unfolding, LWS 
> > cleanup and and list merging to be safe operations on all headers.
>
> Well, I'd say the answer hinges on what "modify" means.
>
> 1. "A recipient MAY replace any linear white space with a single SP
before
>    interpreting the field value or forwarding the message downstream."
>    (Section 2.2, page 16)
>
> 2. "If the response is being forwarded by a proxy, the proxy
application
>    MUST NOT modify the Server response-header." (Section 14.38, page 
> 141)
>
> 3. "MAY   This word, or the adjective 'OPTIONAL', mean that an item is
>    truly optional.  [...] An implementation which does not include a
>    particular option MUST be prepared to interoperate with another
>    implementation which does include the option, though perhaps with
reduced
>    functionality. In the same vein an implementation which does
include a
>    particular option MUST be prepared to interoperate with another
>    implementation which does not include the option (except, of
course, for
>    the feature the option provides.)" (BCP0014)
>
> --
>
> Supposing (1) IS considered modification, if (1) is applied to a 
> Server header, then the implementation is in violation of the spec, as
per (2).
> However, if any application depends on (2), they would be in violation

> of (3) (UNLESS (3) is determined to be null and void in cases where a 
> MUST conflicts with it). Thus, it's technically possible to correctly
implement this interpretation, but it uselessly locks the Server header.
>
> Supposing (1) IS NOT considered modification, we can perform (1) 
> without violating (2). (3) applies as it does for all "modifiable" 
> headers. IMHO, this makes the most sense, but it requires that we
define what "modify"
> means (which gives us the opportunity to take care of the "is deletion

> modification?" question).
>
> I propose adding the following (or something like it) to section 1.3:
>
> modify
>    When applied to headers, "modify" means any change made to the
field-
>    value that alters the semantic meaning of that field. Combining
multiple
>    header fields (see section 4.2) and replacing LWS with a single SP
(see
>    section 2.2) are not considered modifications, nor are any changes
that
>    have been specified as having no semantic meaning. The removal of a
>    header and altering the order of headers that have the same
field-name
>    are both considered to be modifications.
>
>
> -- Travis
>

Received on Thursday, 21 December 2006 20:14:08 UTC