Hi,
I am experiencing a strange problem with a webserver not under my
control, where I am trying to send POST data to.
I am trying to send a requestEntity to a script requiring basic
authentication.
While the whole stuff works when using http, but it fails with a status
400 on the given server when using https.
The strange thing is, that when viewing the access.log on the server,
for a https-post I find the following:
127.0.0.1 [24/Oct/2007:20:20:32 +0200] "POST
/~userhome/some/script.cgi?foo=bar&bar=foo HTTP/1.1" 401 409
127.0.0.1 [24/Oct/2007:20:20:32 +0200] "<?xml version=\"1.0\"
encoding=\"UTF-8\" standalone=\"yes\"?>" 400 299
where as in a http post it looks like this:
127.0.0.1 [24/Oct/2007:20:24:56 +0200] "POST
/~userhome/some/script.cgi?foo=bar&bar=foo HTTP/1.0" 401 397
127.0.0.1 username [24/Oct/2007:20:24:57 +0200] "POST
/~userhome/some/script.cgi?foo=bar&bar=foo HTTP/1.0" 200 17
(Please note, that I replaced the real ip, username and URI with some
replacements)
Now, as you can see, the second line in the failing https post is the
first line of the requestEntity which I am sending which obviously ends
in a 400.
I tried, to replicate the whole problem on a webserver under my control,
trying to match the original server's setup. The only difference on my
setup is, that the script is not residing in a ~userdir.
But, as you probably alreadey imagine, the whole test on the test server
worked as expected and I got a valid authenticated post line in the
access log.
I also tried to compare the httpclient debug outputs of sending the same
stuff to the working and the non-working https server. The only
difference I noticed is already after I received the status codes. The
working server sent a
header:70 - << "Transfer-Encoding: chunked[\r][\n]"
while the non-working sent a
header:70 - << "Connection: close[\r][\n]"
at the same position.
BTW, the working server identified himself as
header:70 - << "Server: Apache/1.3.26 Ben-SSL/1.48 (Unix) Debian
GNU/Linux PHP/4.1.2[\r][\n]"
while the non-working was
header:70 - << "Server: Apache/1.3.31 (UnitedLinux) mod_ssl/2.8.19
OpenSSL/0.9.6g[\r][\n]"
So much for describing my problem. I don´t know, if this mailing list is
the correct adress to post this issue, but maybe somebody already
expirienced as similar problem. And maybe you could help me find out if
the problem is caused by the client- or the server-side.
Any suggestions?
Thanks,
Philipp
BTW.: This is the source I am using to test the POST:
import java.io.File;
import java.io.IOException;
import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.HttpException;
import org.apache.commons.httpclient.UsernamePasswordCredentials;
import org.apache.commons.httpclient.auth.AuthScope;
import org.apache.commons.httpclient.methods.FileRequestEntity;
import org.apache.commons.httpclient.methods.PostMethod;
import org.apache.commons.httpclient.methods.RequestEntity;
public class EHubTest {
/**
* @param args
*/
public static void main(String[] args) {
String strUrl =
"https://www.some.host/~userhome/some/script.cgi?foo=bar";;
File input = new File("file.xml");
PostMethod method = new PostMethod(strUrl);
RequestEntity entity = new FileRequestEntity(input, "utf-8");
method.setRequestEntity(entity);
HttpClient client = new HttpClient();
client.getState().setCredentials(new AuthScope("www.some.host",
443), new UsernamePasswordCredentials("Username", "password"));
try {
int result = client.executeMethod(method);
System.out.println("Response status code: " + result);
// Display response
System.out.println("Response body: ");
System.out.println(method.getResponseBodyAsString());
} catch (HttpException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
