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

Eduardo Casais wrote:
[...]
> 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."

I'm fine with that.


[...]
> 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.

I'm mostly fine with that as well, except:

  a. I do not understand the reference to 4.1.1 that deals with the HTTP 
method of the request

  b. "other published standards in force" seems out of place, and/or 
vague. All of them should be based on RFC2616, and although I think it 
is fine being a bit more restrictive in other standards (although one 
quickly becomes accused of "Profiling HTTP"), I do not think one can be 
less restrictive (e.g. modifications of the HTTP Header that may be 
defined in UAProf should still respect RFC2616). Do you have an example 
in mind that would require the addition of such a loose reference?

  c. (3) does not result in such a strong statement in practice, in 
that, AFAICT (but I may have missed a section), RFC2616 does not forbid 
proxies from inserting additional HTTP header fields (save a few 
specific ones) for instance. I haven't found any statement that forbids 
deletion of HTTP headers either. That said, (3) is still right, just 
looks stronger than it really is. I do not have any better proposal.

  d. I suppose that by "redactional melding", you are referring to the 
list of exceptions to the rules when "capabilities" HTTP header may be 
modified. Or did you mean to suppress that altogether? I'm all for 
keeping it.

Francois.

Received on Monday, 1 December 2008 16:11:22 UTC