WHAM!! Forcing httpclient to use HTTP/1.0 succeeded with http and https. Thank you very much, sebb. I don´t know WHY this is, but currently I am happy, that it is finally working. BTW, I made another test before, tunneling a http request through stunnel to the https-server. This worked as well and it USED HTTP/1.1 . So this makes me assume, that the problem is still somewhere on the client-side. If some httpclient-developer is investigating into this problem any further, I would be willing to help out, but I won´t have any access to the particular server.
Best regards, Philipp sebb schrieb: > The HTTP version is defined in a parameter: > > See the example here: > > http://jakarta.apache.org/httpcomponents/httpclient-3.x/preference-api.html > > BTW, it would help to know which version you are using. > > On 25/10/2007, Philipp Leusmann <[EMAIL PROTECTED]> wrote: > >> Hi sebb, >> >> very interesting observation. I must have missed that and it is not a >> transcription error. >> Anybody can explain why httpclient is sending the http-request as >> HTTP/1.0 but https as HTTP/1.1? Can I force httpclient to use HTTP/1.1 >> for the http request (or vice versa) as well, to check if this is the >> error cause? >> >> Thanks, >> Philipp >> >> sebb schrieb: >> >>> I can't offer any help, but I notice that the first (https) exchange >>> has HTTP/1,1 whereas the second (http) says HTTP/1.0. >>> >>> Or is that a transcription error? >>> >>> On 25/10/2007, Philipp Leusmann <[EMAIL PROTECTED]> wrote: >>> >>> >>>> 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(); >>>> } >>>> } >>>> >>>> } >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
