Re: Duplicated guidelines for Web Content Transformation Proxie

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Duplicated guidelines for Web Content Transformation Proxie

Eduardo Casais
> In 4.1.5 [1], the normative statement:
> [[ It must be possible for the server to reconstruct the
> original User Agent originated header fields by copying
> directly from the corresponding X-Device header field
> values (see 4.1.5.5 Original Header Fields). ]]
>
>... refers to 4.1.5.5 [2] where it is more properly defined:
> [[ When forwarding an HTTP request with altered HTTP
> header fields, in addition to complying with the rules of
> normal HTTP operation, proxies must include in the
> request copies of the unaltered header field values
> in the form "X-Device-"<original header name>. ]]
>
> From a normative point of view, the first statement does
> not add anything. I understand it is there for emphasis,
> but could perhaps be turned into an informative
> statement that delegates to 4.1.5.5

There is a subtle, but important point in the first statement
(which was added at my insistence, by the way): it
ensures that one does not have to interpret or parse the
values in the X-Device fields in any new way -- one can
just copy the field values and thus recuperate directly the
original header fields.

The second statement strictly states that the X-Device
fields must include copies of the original values, but by
itself does not prevent the addition of extra content, or
bracketing the original values within something else (for
instance, placing the original field values within some XML
markup tags, that would have to be parsed out when
recuperating the original string).

This is why there is no redundancy in this case.

As for 4.1.5.5, the sentence "For example, if the
User-Agent header field has been altered, an
X-Device-User-Agent header field must be added..."
could be changed so that the must is no longer
emphasized in the way denoting a normative statement.


E.Casais




     

Reply | Threaded
Open this post in threaded view
|

Re: Duplicated guidelines for Web Content Transformation Proxie

Francois Daoust
Eduardo Casais wrote:

>> In 4.1.5 [1], the normative statement:
>> [[ It must be possible for the server to reconstruct the
>> original User Agent originated header fields by copying
>> directly from the corresponding X-Device header field
>> values (see 4.1.5.5 Original Header Fields). ]]
>>
>> ... refers to 4.1.5.5 [2] where it is more properly defined:
>> [[ When forwarding an HTTP request with altered HTTP
>> header fields, in addition to complying with the rules of
>> normal HTTP operation, proxies must include in the
>> request copies of the unaltered header field values
>> in the form "X-Device-"<original header name>. ]]
>>
>> From a normative point of view, the first statement does
>> not add anything. I understand it is there for emphasis,
>> but could perhaps be turned into an informative
>> statement that delegates to 4.1.5.5
>
> There is a subtle, but important point in the first statement
> (which was added at my insistence, by the way): it
> ensures that one does not have to interpret or parse the
> values in the X-Device fields in any new way -- one can
> just copy the field values and thus recuperate directly the
> original header fields.
>
> The second statement strictly states that the X-Device
> fields must include copies of the original values, but by
> itself does not prevent the addition of extra content, or
> bracketing the original values within something else (for
> instance, placing the original field values within some XML
> markup tags, that would have to be parsed out when
> recuperating the original string).
>
> This is why there is no redundancy in this case.
>

OK, I understand the difference and the need to be more precise. I
realize that it is not easy to adjust the wording of 4.1.5.5 to
precisely explain what proxies must do. I still think that this is what
we should do. At a minimum, these two highly-related points should be
found under the same paragraph.

Since "copying directly" is used in 4.1.5 as the expression to prevent
the addition of extra content and other bracketing stuff, can we use
"direct copy", "verbatim copy" or "exact copy" in 4.1.5.5?


Proposal 1: the same with "direct copies"
-----
When forwarding an HTTP request with altered HTTP header fields, in
addition to complying with the rules of normal HTTP operation, proxies
must include in the request *direct copies* of the unaltered header
field values in the form "X-Device-"<original header name>.


Proposal 2: looks more complex but is easier to parse with algorithmic
eyes, I think.
-----
When forwarding an HTTP request, for each altered HTTP header field that
is not the result of complying with the rules of normal HTTP operation,
proxies MUST include in the request an "X-Device-"<original header name>
HTTP header field whose value is a direct copy of the original header
field value.


I also updated "in addition to complying with the rules of normal HTTP
operation" in that second proposal. I think it is there to exclude e.g.
alterations in a Via HTTP header field that are required by RFC2616 for
proxies so as not to end up with an X-Device-Via HTTP header field.
That's another point where we could be slightly more precise for the
benefit of readers. This comment could be similar to the last call
comment LC-2319 from Mark on 4.1.5:
 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2319


As mentioned in my previous email, I make these proposals while thinking
about a test suite for the guidelines. It is easier to test statements
that do not have to be assembled from different places in the spec. This
should be true for implementers as well.


> As for 4.1.5.5, the sentence "For example, if the
> User-Agent header field has been altered, an
> X-Device-User-Agent header field must be added..."
> could be changed so that the must is no longer
> emphasized in the way denoting a normative statement.

+1.

Francois.

>
>
> E.Casais