Thanks for your friendly words and explanations. Due to your thought the POST data of the first request may get processed too late and mixup things, I altered the client source, so the user credentials are only send after the inital call (on the second request). Also the POST test data "testName=testValue" is only send after the 302 redirect. Sadly the responses stay the same as before.
Now, I don't know what to try next to narrow the problem down. Still, I'm unsure if the problem lies in the clientCode/API or on the Tomcat side? Any suggestions? best regards Hans 2010/8/13 André Warnier <a...@ice-sa.com>: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
