W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

RE: Intent of 14.38 Server

From: Travis Snoozy (Volt) <a-travis@microsoft.com>
Date: Thu, 21 Dec 2006 10:16:44 -0800
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <86EDC3963F04D546BED8996F77D290F6049D1178F8@NA-EXMSG-C138.redmond.corp.microsoft.com>

Henrik Nordstrom said:

> 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:

   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:16:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:40 UTC