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 Wednesday, 26 March 2008 18:08:52 UTC