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 18:46:11 UTC