RE: Request bodies alteration and character encoding issue

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

I agree, there is a slippery slope here. And we are in danger of sliding down it.

We are not trying to specify how a CT proxy works, so I think we should stick to things that the Transforming Proxy SHOULD NOT [rfc2119] do because they make the CP's life a misery and things they SHOULD do to make the CP's life easier. I'm thinking that with those rules in mind, we don't need to go in to the details of how a CT Proxy actually does what it does in this case, because it is transparent to the proxy. 

So what we should say, I think, as you suggest Franscois, is say that any manipulation that the CT proxy does of the request body must/should be transparent to the CP. 

Jo

> -----Original Message-----
> From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Francois Daoust
> Sent: 08 April 2008 11:30
> To: Aaron Kemp
> Cc: public-bpwg-ct
> Subject: 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 11:06:28 UTC