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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
