Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4C654BD4.8040105@ice-sa.com>
Date: Fri, 13 Aug 2010 15:42:44 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: 501 Method not implemented with successive POST requests
References: <AANLkTi=3dRO0GXvC4W=W1p3bAYACH6SRmGK=WtHWcfnh@mail.gmail.com>
	<4C651639.8000700@pidster.com>
	<AANLkTi=8G8-m34GMczU8+gt5=SSkCbPPE1BoVehvh6Nh@mail.gmail.com>
	<4C653B18.4060702@pidster.com>
 <AANLkTiki09a4M7WtbJVDRAu30VVhJ14CBTHMBDytojv-@mail.gmail.com>
In-Reply-To: <AANLkTiki09a4M7WtbJVDRAu30VVhJ14CBTHMBDytojv-@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hans Wahn wrote:
>> For the below, isn't there an alternative method of configuring the
>> client to automatically follow redirects?
> 
> I asked the same question and Oleg Kalniche (HTTPComponents developer) replied:
> 
> "There are several cases when automatic redirections is prohibited by the
> HTTP specification. You can provide a custom RedirectHandler (4.0) or
> RedirectStrategy (4.1) implementation in order to override those
> restrictions. Per default HttpClient automatically redirects 302
> responses only for GET and HEAD methods."
> 
> 
> It is also weird that the first response after the redirect is ok, but
> the next fails while all responses after the failure are fine.
> 
> 
Hi.
First, congratulations on the excellent information you are providing about the problem.
Wish everyone did similarly.

Here are a couple of considerations that might be relevant or not to the issue at hand, 
but maybe this gives you an idea.

 From the HTTP RFC point of view, a POST request is something that might trigger a change 
of the data on the server side (think POST-ing a payment from your bank account).
That is why a POST cannot just be repeated, without at least asking the client about it 
(you do not want to risk paying twice).

In a general sense, it is also risky to use a POST as the first request to an area 
submitted to authentication.  Remember that HTTP is, at the base, a connection-less 
protocol (each request/response is independent of the others, and the server could have 
processed a million other requests before this client makes his second request).

The first time the client makes the POST (request + headers + data), the client is not yet 
authenticated.  So the server has to refuse, and send back a request for authentication, 
before accepting the POST (e.g. the authentication form, or a 401 response).  Then the 
client has to respond to this authentication request (in this case, by submitting the 
login form contents).  Then the server has to verify the credentials, and if they are ok, 
then the client could now re-submit its POST.
But there is an inherent problem there : where has the POST data from the first 
unsuccesful POST gone in the meantime ?
And can the client just re-submit that same POST now, with the same data ?
What if the server, upon the succesful authentication, had somehow remembered it and 
processed it ?
(that is why in most browsers, you get a warning popup when moving back to a previous page 
and try to issue the same POST request as before).

There are schemes to overcome the above issue, where the server indeed remembers the POST 
body and does an internal redirect when the authentication has succeeded.  But I wonder if 
this works with a form-based authentication scheme.

My second consideration is that by examining you data, I see that each request seems to be 
split in 2 phases :
1) client sends the request line and the headers, including a "Expect: 100-Continue" header
1a) server responds "HTTP/1.1 100 Continue[EOL]"
2) client sends the request body

I am unfamiliar with that scheme (which may be very correct in HTTP terms).
But maybe that is when the server and/or client get confused, when this is mixed with an 
authentication scheme ?
Or maybe the client is not just supposed to send the rest of the request without a header 
of some sort ?

Third consideration : in the requests from the client to the server, I see a "Connection: 
Keep-Alive" header.  But I see no such headers coming back from the server.
Maybe it is implied in that case (I have not rechecked the RFC).
But could this not be the origin of the problem ? If the server sends a 100 Continue, but 
then closes the connection, then the next client request which just sends the remaining 
body (on a new connection?), may be interpreted by the server as a new request (on this 
new connection), and thus not be understood properly, and generate this "method not 
implemented".

HTH, somehow


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org