Re: Bug 1.2RC3-1.2: Using CommonsHttpClient fails
unfortunately the patch it's not working for me.
what am I'm doing wrong?
I added this to my stub code:
protected void setUserHeader( MessageContext msgContext ) {
Hashtable userHeaderTable = new Hashtable();
userHeaderTable.put(HTTPConstants.HEADER_TRANSFER_ENCODING_CHUNKED,
false);
msgContext.setProperty(HTTPConstants.REQUEST_HEADERS,
userHeaderTable );
}
org.apache.axis.client.Call _call = createCall();
_call.setOperation(_operations[0]);
_call.setUseSOAPAction(true);
_call.setSOAPActionURI();
_call.setSOAPVersion(org.apache.axis.soap.SOAPConstants.SOAP11_CONSTANTS);
_call.setOperationName(new
javax.xml.namespace.QName(urn:Eusoda, lastChange));
setUserHeader( _call.getMessageContext() );
I'm still getting the old error message. I didn't update the code on the
server side, but I think this is not necessary, right?
I have used this nightly build:
axis-bin-1_2_1.zip 09-Jun-2005 21:07 11M
regards,
andreas
Re: Bug 1.2RC3-1.2: Using CommonsHttpClient fails
I have seen it. great! so, let's hope for new release :) Mike Moran wrote: Andreas Bohnert wrote: Yepp, I just did it. But maybe it would be helpful to post your fix to the database as well?! what do you think? I've updated http://issues.apache.org/jira/browse/AXIS-2033 with the code which worked for me (just in case you missed a notification)
Bug 1.2RC3-1.2: Using CommonsHttpClient fails
hi list,
I found a bug if the common http client is used. this bug can be
reproduced with 1.2 final and 1.2.1 nightly build.
with 1.2RC3 it works fine!
with new releases I can't call my webservice from my client anymore. I
get this:
2005-06-02 11:45:24,291 WARN [main] httpclient.HttpMethodBase - Going
to buf
fer response body of large or unknown size. Using getResponseAsStream
instead
is recommended.
2005-06-02 11:45:24,298 ERROR [main] exchange.ExchangeServiceClient -
(411)Le
ngth Required
AxisFault
faultCode: {http://xml.apache.org/axis/}HTTP
faultSubcode:
faultString: (411)Length Required
faultActor:
faultNode:
faultDetail:
{}:return code: 411
lt;!DOCTYPE HTML PUBLIC quot;-//IETF//DTD HTML 2.0//ENquot;gt;
lt;HTMLgt;lt;HEADgt;
lt;TITLEgt;411 Length Requiredlt;/TITLEgt;
lt;/HEADgt;lt;BODYgt;
lt;H1gt;Length Requiredlt;/H1gt;
A request of the requested method POST requires a valid
Content-length.lt;P
gt;
chunked Transfer-Encoding forbidden: /exchangelt;Pgt;
lt;HRgt;
lt;ADDRESSgt;Apache/1.3.33 Server at www.myserver.net Port 80lt;/A
DDRESSgt;
lt;/BODYgt;lt;/HTMLgt;
{http://xml.apache.org/axis/}HttpErrorCode:411
(411)Length Required
at
org.apache.axis.transport.http.CommonsHTTPSender.invoke(CommonsHTT
PSender.java:208)
at
org.apache.axis.strategies.InvocationStrategy.visit(InvocationStra
tegy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2765)
at org.apache.axis.client.Call.invoke(Call.java:2748)
at org.apache.axis.client.Call.invoke(Call.java:2424)
at org.apache.axis.client.Call.invoke(Call.java:2347)
at org.apache.axis.client.Call.invoke(Call.java:1804)
at
at.weberhofer.eusoda.client.services.exchange.ExchangeSoapBindingS
tub.lastChange(ExchangeSoapBindingStub.java:466)
at
at.weberhofer.eusoda.client.services.exchange.ExchangeServiceClien
t.clientPollsTransaction(ExchangeServiceClient.java:90)
at
at.weberhofer.eusoda.client.services.exchange.ExchangeServiceClien
t.replicate(ExchangeServiceClient.java:354)
at
at.weberhofer.eusoda.client.services.exchange.ExchangeServiceClien
t.replicate(ExchangeServiceClient.java:233)
at
at.weberhofer.eusoda.client.services.exchange.ExchangeServiceMain.
main(ExchangeServiceMain.java:38)
should I but this in the bug database?
regards, andreas
Re: Bug 1.2RC3-1.2: Using CommonsHttpClient fails
On 2 Jun 2005, at 12:27, Andreas Bohnert wrote: hi list, I found a bug if the common http client is used. this bug can be reproduced with 1.2 final and 1.2.1 nightly build. with 1.2RC3 it works fine! with new releases I can't call my webservice from my client anymore. I get this: [ ... content length related trace ... ] This sounds like what I found: The problem is that, because CommonsHTTPSender.MessageRequestEntity#getContentLength() is defined to only return a content-length when the HTTP version is 1.0 *and* no exception is thrown from message.getContentLength(), then it will not even try if the HTTP version is 1.1. The upshot of this is that a Transfer-Encoding: chunked header is set on the request. (see http://marc.theaimsgroup.com/?l=axis-devm=111523156110949w=2) should I but this in the bug database? I think you should. I didn't put it in because it only affected me and I patched the src to work round it. It's also technically ok, I think, but from what you've found it seems like it might not or it might make sense to always default to sending content-length; I can't see any reason why Transfer-Encoding: chunked is the default. -- Mike http://www.houseofmoran.com/blog/
Re: Bug 1.2RC3-1.2: Using CommonsHttpClient fails
Yepp, I just did it. But maybe it would be helpful to post your fix to the database as well?! what do you think? regards, andreas Mike Moran wrote: On 2 Jun 2005, at 12:27, Andreas Bohnert wrote: hi list, I found a bug if the common http client is used. this bug can be reproduced with 1.2 final and 1.2.1 nightly build. with 1.2RC3 it works fine! with new releases I can't call my webservice from my client anymore. I get this: [ ... content length related trace ... ] This sounds like what I found: The problem is that, because CommonsHTTPSender.MessageRequestEntity#getContentLength() is defined to only return a content-length when the HTTP version is 1.0 *and* no exception is thrown from message.getContentLength(), then it will not even try if the HTTP version is 1.1. The upshot of this is that a Transfer-Encoding: chunked header is set on the request. (see http://marc.theaimsgroup.com/?l=axis-devm=111523156110949w=2) should I but this in the bug database? I think you should. I didn't put it in because it only affected me and I patched the src to work round it. It's also technically ok, I think, but from what you've found it seems like it might not or it might make sense to always default to sending content-length; I can't see any reason why Transfer-Encoding: chunked is the default.
