You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Philipp Leusmann <ph...@rwth-aachen.de> on 2007/10/25 13:20:00 UTC
POST request contains data from request entity
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();
}
}
}
Re: POST request contains data from request entity
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2007-10-25 at 14:48 +0200, Philipp Leusmann wrote:
> 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
>
Philipp
Please post wire logs of all HTTP sessions (plain http/1.0, plain
http/1.1, https/1.0 and https/1.1)
http://jakarta.apache.org/httpcomponents/httpclient-3.x/logging.html
Oleg
> 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 <ph...@rwth-aachen.de> 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 <ph...@rwth-aachen.de> 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: httpclient-user-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: POST request contains data from request entity
Posted by Philipp Leusmann <ph...@rwth-aachen.de>.
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 <ph...@rwth-aachen.de> 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 <ph...@rwth-aachen.de> 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: httpclient-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
Re: POST request contains data from request entity
Posted by sebb <se...@gmail.com>.
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 <ph...@rwth-aachen.de> 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 <ph...@rwth-aachen.de> 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: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: POST request contains data from request entity
Posted by Philipp Leusmann <ph...@rwth-aachen.de>.
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 <ph...@rwth-aachen.de> 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: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
Re: POST request contains data from request entity
Posted by sebb <se...@gmail.com>.
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 <ph...@rwth-aachen.de> 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: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: POST request contains data from request entity
Posted by Philipp Leusmann <ph...@rwth-aachen.de>.
One thing I forgot to mention:
when switching the non-working server to not use password
authentication, but to grant access based on the IP I was sending from,
thus not sending the first 401 response, the POST worked like a charm.
Regards,
Philipp
Philipp Leusmann schrieb:
> 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: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org