Re: [CTG] Alteration of header fields (4.1.5) / inconsistencies

> I'm sure I forgot something important here. What is it? ;-)

I believe that we are almost there; the approach you suggest
is the right one.

> ... and propose to adjust the wording of section 4.1.5.5 
> consequently only to refer to User-Agent and Accept(-*) 
> headers (which we have to do anyway if we are to register 
> the X-Device-* headers in any proper way)

You are right, these fields must be identified accurately.
I suggest we insert the following definitions in 4.1.5.5:

"Capability fields are the HTTP header fields User-Agent,
Accept, Accept-Charset, Accept-Encoding, Accept-Language.

Backup capability fields are HTTP header fields corresponding
to capability fields and named X-Device-User-Agent, 
X-Device-Accept, X-Device-Accept-Charset, X-Device-Accept-Encoding, 
X-Device-Accept-Language, respectively. The value of a backup
capability field is the same as the value of the corresponding
capability field as originally sent by the terminal user-agent."

> In short, I propose something along the lines of:
> "
>  Proxies SHOULD NOT modify the User-Agent and Accept(-*) headers unless:
>   [list of 3 possibilities, possibly amending the third one]
>  Proxies MUST NOT delete headers.
>  It MUST be possible to reconstruct the original User-Agent and
> Accept(-*) headers (see 4.1.5.5)"

This leaves ambiguities as to how to reconstruct original values,
how to update the X-Device-* fields, and so on. We can make the 
proposed statement in 4.1.5 clearer thus:

"Except as specified in sections 4.1.1, 4.1.6, 4.1.6.1, 4.2.4 of 
the present document, and except as prescribed by RFC2616 and other 
published standards in force, a proxy
1. SHOULD NOT modify capability fields and MUST NOT delete them;
2. MUST NOT modify backup capability fields;
3. MUST NOT alter the remainder of the HTTP header in any way.

If a proxy modifies a capability field and no corresponding 
backup capability field is present in the HTTP header, then 
it MUST, prior to modification, insert a corresponding backup
capability field whose value is the original value of the 
capability field in question. If the request does not include 
the capability field, and the proxy introduces it into the 
HTTP header, then the corresponding backup capability field 
MUST be assigned the empty value. The proxy MUST NOT introduce 
duplicate capability fields.

If a proxy deletes a backup capability field, then it MUST,
prior to deletion, re-assign its value to the corresponding
capability field."


Some redactional melding with the remainder of 4.1.5 may
still be needed.

Rationale:

The statements make sure that one modifies the request safely
and can always reconstruct the original request, because

a) The X-Device-* fields always contain the original values
and are never overwritten; there are no duplicate X-Device-*
so that no confusion as to the order of updates arises.

b) Whenever a X-Device-* field is deleted, the original field
is restored with the original value.

c) If the terminal does not send some field, then it is 
possible to introduce them, but a X-Device-* field indicates
that the original field was empty. Yes, this happens, for
instance many i-Mode devices do not send Accept and 
Accept-Charset.

d) The rest of the HTTP header remains untouched (no
insertions, deletions, suppressions) except as prescribed
by standards (yes, other standards than RFC2616, e.g. UAProf,
may allow alterations of the HTTP header) or as necessary 
for the other limited operations in the CTG.


E.Casais

Received on Monday, 1 December 2008 15:05:56 UTC