Re: Request bodies alteration and character encoding issue

Thanks Aaron!

Thinking out aloud, trying to summarize and reformulate it from a 
different angle:

In short, the CT-proxy only alters request bodies for requests based on 
responses that were already transformed: if an HTTP response containing 
a form is sent unaltered to the client, the following form submission 
request won't be altered by the CT-proxy.

This could lead to two guidelines to replace current editorial note in 
4.1.2 [1]:

1. the CT-proxy MUST NOT alter the request method and body of a request 
that originates from an untransformed web page. Note it may still change 
the headers though.

2. if the origin web page was transformed, the CT-proxy MUST (actually, 
it's a "must" as in "it's the only it can work anyway") alter the 
request method and body of the request to match that of what the request 
would have been had the origin page not been transformed. In other 
words, the CT-proxy "simply" MUST ensure that its changes are 
transparent from the content provider's point of view.

(both points obviously need some re-wording to make things clear)

... and the list of examples could be examples of "restructuring" and 
"recoding" transformations made by a CT-proxy. It could go in "Types of 
transformation" (§2.2), or we may simply not mention them.

As for the prescriptions that may have to be made about transformation 
of request bodies, they are rather prescriptions about transformation of 
the origin response, IMO. I'm not sure we want to go deep into details 
there.

François.

[1] 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080403#sec-decision-to-transform



Aaron Kemp wrote:
> Sorry this is so late, just digging out from vacation.
> 
> On Tue, Mar 18, 2008 at 1:09 PM, Francois Daoust <fd@w3.org> wrote:
>>  Should we rather use an affirmative form such as "Proxies MAY alter request
>> bodies, typically when [above blah]"?
>>  Should we just say nothing?
> 
> I guess I'd vote to either say they MAY or just note that it occurs in practice.
> 
>>  Just to make sure I understand: the form that uses GET is converted to a
>> form that uses POST when the HTTP response that contains the form is sent to
>> the user. The user thus issues a POST request which is then converted back
>> to a GET request by the CT-proxy. In other words, from the origin server's
>> point of view, the form still uses GET. Am I right?
> 
> Exactly.  The origin server doesn't notice because nothing changes.
> 
>>  That's more than "altering request body". It's "altering request method".
>> We may want to add that as well.
> 
> Right.
> 
>>  Note that my second question would be: could you precise "a variety of
>> reasons"? I can think of URI that would become too long, although I remember
>> having had this problem six years ago, so I'm not sure it's still an issue
>> in practice in 2008.
> 
> URIs definitely can become too long (phones are more limited than
> desktop browsers, as are the gateways in between sometimes).  It's
> also to prevent casual snooping, and finally, we use our own URL
> parameters, so we'd have to ensure the user submitted form values
> didn't collide with ours.
> 
> Aaron
>

Received on Tuesday, 8 April 2008 10:30:54 UTC