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

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

Oops, typo. To be deleted.

> b. "other published standards in force" seems out of
> place, and/or vague. 

It is vague, but the fact is that there are standards that extend the HTTP header with their own fields, and which prescribe how these extra fields must be inserted, modified and deleted. UAProf is an example. There are possibly others (knowledgeable people, please send references!) 

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

The intent is not to restrict these other standards, on the contrary, but to put them on the same footing as RFC2616 (i.e. "except as prescribed by RFC2616 and other published standards in force..."). The idea is that if RFC2616 or any other standard (e.g. UAProf) tells you  SHOULD/MUST/MAY/etc, then proxies must do their job accordingly. Otherwise, do not touch the HTTP header.

> (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.

We are considering good practices for the operation of CT-proxies. In this context, apart from those alterations that RFC2616, UAprof, etc, and the CTG itself define, is there any reason for CT-proxies to alter the HTTP header for transcoding operations? No. In fact, application developers have been quite distracted by some deployed transcoders that delete, for instance, the X-Wap-Profile field -- hence eliminating the detailed description of the terminal capabilities upon which they rely to deliver mobile-optimized content.

>From that perspective, stipulating "this is how a CTG-compliant proxy behaves; RFC2616 might give you the freedom to turn the HTTP header upside down, but wild alterations do not serve any purpose for transformations, hinder applications, do not constitute good practice, and are therefore disallowed for CTG-conformant proxies."

This being said, I realize that you are right that the formulation of (3) is perhaps too strong. It should be modified to "MUST NOT modify or delete the fields in the remainder of the HTTP header" -- which still allows the insertion of proprietary fields.

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

The former; I am just unsure where to insert the list.

E.Casais

Received on Tuesday, 2 December 2008 09:49:45 UTC