From: firstname.lastname@example.org (Koen Holtman) Message-Id: <199803261928.UAA06028@wsintt15.win.tue.nl> To: email@example.com (Koen Holtman) Date: Thu, 26 Mar 1998 20:28:31 +0100 (MET) Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: comments on draft-ietf-http-ext-mandatory-00.txt Oops, I just realised that my analysis of the 304 problem was incomplete: Koen Holtman: > >- also in 3.1: > > `Agents SHOULD NOT reuse header-prefix values in the same message > unless explicitly allowed by the extension (see section 4.1 for a > discussion of the ultimate recipient of an extension declaration).' > > The parenthetical remark is a bit strange (why is that discussion > relevant to that rule?), but the rule itself is clear. However, I > realised yesterday that this rule alone will not prevent all > possible clashes of header-prefix values. A case where it can still > go wrong: > > 1. suppose a 1.x proxy cache (which is not aware of the mandatory > spec) has cached a response with the headers > > opt: "blex"; ns=123 > 123-p: t > > in it > > 2. suppose the cache is caused to to revalidate this response: it > sends a conditional request towards the origin server > > 3. the response is still fresh so the origin server sends a 304 > > 4. some intermediate party tacks an extension onto the 304 ^^^^^^^^^^^^^^^^^^^^^^^ Should be: some other extension inside the origin server or an extension in a proxy acting as the agent of the origin server > response, adding the headers > > opt: "zoiks"; ns=123 > 123-q: f > > 5. on receipt, the proxy follows this part of the 1.1 spec: > ># If a cache uses a received 304 response to update a cache entry, the ># cache MUST update the entry to reflect any new field values given in ># the response. > > to the headers in the updated response are, I guess: > > opt: "zoiks"; ns=123 > 123-p: t > 123-q: f > > 6. the zoiks extension in the ultimate recipient of the response > may proceed to do the wrong thing on seeing `123-p: t' > > I guess this problem can be fixed by forbidding the use of header > prefixes in 304 responses. This should not be too big a loss I > think. I just realised that you also may want to forbid man: headers in 304 responses altogether as they may overwrite an already-existing man header in the cached entry. On a related issue: does anybody have any real experience with what deployed proxies (especially 1.0 proxies) do to meet the `MUST update the entry to reflect any new field values' requirements of 1.1 and 1.0? Koen.