RE: ACTION-685: message/http, message/external-body and/or use of WARNING headers for 3.1.4

> Replying to myself, following Jo's comment during last call re bodies
in
> GET requests:
If you want intelligent conversation, talking to yourself is one option,
I suppose :-)

I think I agree with you here. In any case, on reflection, how would you
get hold of the data on a typical server? In the case of a POST it would
need to follow the format of multipart/form-data, presumably? And I
think you could probably find a way of embedding a part describing the
original request. And you could probably define some magic filename or
something to allow servers to pull the data out. But that probably
wouldn't work for GET would it?

Just musing really, I think this is a "dead duck"

Jo

> -----Original Message-----
> From: Francois Daoust [mailto:fd@w3.org]
> Sent: 26 March 2008 18:08
> To: public-bpwg-ct; Jo Rabin
> Subject: Re: ACTION-685: message/http, message/external-body and/or
use of
> WARNING headers for 3.1.4
> 
> Replying to myself, following Jo's comment during last call re bodies
in
> GET requests:
> 
> Francois Daoust wrote:
> > 4/ What about GET requests? We may think we could use 1/ in that
case
> > (no POST data in that case). The HTTP RFC doesn't state that request
> > bodies can't be used in GET requests. In practice, this means that
the
> > behavior of agents regarding GET requests with bodies in
unpredictable,
> > and that we can't rely on anything.
> 
> Let's suppose we can use bodies in GET requests...
> 
> As there's no way to do that in POST requests, we're going to end up
> with something that strikes me as odd to handle the following (common)
> case:
> a) a GET request on a page. The CT-proxy changes the headers and
embeds
> the original ones in the GET body.
> b) the server discovers the original headers, uses them and send a
> response to the user adapted to the user's mobile phone.
> c) the response contains a form that the user fills out and submits.
> d) the form is submitted via a POST request, as most well-designed
forms
> should be.
> e) the CT-proxy behaves coherently, and since it altered the headers
in
> the GET request, it also alters the headers in the POST request. It
> can't embed the original headers in a POST request though.
> f) the server receives the form, but not the original headers... It
> can't tell which terminal the user is using and now replies to the
> altered request.
> 
> In that case, the burden would be on the content provider in the sense
> that he would have to embed the original headers in the response
himself
> so that they are sent along with the form as POST data.
> 
> -> I would say that the solution to pass on the original headers MUST
> work no matter the HTTP method. This solution only would work for GET
> requests. Am I missing something?

Received on Thursday, 27 March 2008 11:01:08 UTC