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.

Received on Thursday, 26 March 1998 14:28:39 UTC