HTTP/1.1 400 No client certificate chain in this request
Our setup:
We have an Axis2 1.3 web service client hitting a 3rd party web service
running on a JBoss server w/ Apache Coyote. We do not know what
package(s) were used to developer the server-side.
We need to connect via SSL using certificate authentication.
The basic payload of the web service is a series of updates. Our client
code runs once per day, grabs any updates in our system since the last
run, and sends them on to the server's web service. We can have
anywhere from 0 to a few hundred updates to send.
The problem comes with the amount of updates we have to send. If we
only have a few (1-3) everything runs fine. We send our data up, we
authenticate properly and receive a successful return from the server.
At around 4 or 5 updates (depending on the actual amount of data in the
updates) or rather once we cross 4096 bytes in the request body, we
start receiving errors. If we up it a bit more, say 10 or more updates,
we receive a different error. We've done some investigation and found
several suggestions to turn off HTTP Chunking in the request. We've
done that and we still get the error. We've also tried swapping to HTTP
1.0, as well as increasing the maxHttpHeaderSize on the server-side
JBoss Connector. All with no luck. We attempted to use TCPMON to watch
the transactions go across, but when we turned SSL and Certificate
Authentication off (as we understand is needed for TCPMON to work),
everything worked fine.
We do have a local copy of the 3rd party server that we are testing
against and can make configuration changes to Coyote/JBoss if needed for
testing. However, we have no access to the server-side web service
code, other than through decompliation.
Any help or pointers anyone can offer would be greatly appreciated.
Results with 4-5 updates
The header:
2008/11/18 16:33:58:081 EST [DEBUG] header - HTTP/1.1 500 Internal
Server Error[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Server:
Apache-Coyote/1.1[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - X-Powered-By: Servlet
2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA
date=200710221139)/Tomcat-5.5
[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Content-Type:
text/xml;charset=utf-8[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Transfer-Encoding:
chunked[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Date: Tue, 18 Nov 2008
21:32:38 GMT[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Connection:
close[\r][\n]
The body:
S:Fault xmlns:ns4=http://www.w3.org/2003/05/soap-envelope;
faultcodeS:Server/faultcode
faultstringjavax.xml.soap.SOAPException:
com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block in
start tag#xD;[\n] at [row,col {unknown-source}]: [1,4096]/faultstring
detail
ns2:exception xmlns:ns2=http://jax-ws.dev.java.net/;
class=javax.xml.ws.WebServiceException note=To disable this feature,
set com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace
system property to false
messagejavax.xml.soap.SOAPException:
com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block in
start tag#xD;[\n] at [row,col {unknown-source}]: [1,4096]/message
ns2:stackTracens2:frame
class=com.sun.xml.ws.handler.SOAPMessageContextImpl
file=SOAPMessageContextImpl.java line=81 method=getMessage/
ns2:frame
class=com.theirpackage.utils.logging.SOAPLoggingHandler
file=SOAPLoggingHandler.java line=73 method=log/
...
ns2:cause class=javax.xml.soap.SOAPException note=To disable
this feature, set
com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace system
property to false
messagecom.ctc.wstx.exc.WstxEOFException: Unexpected end
of input block in start tag#xD;[\n] at [row,col {unknown-source}]:
[1,4096]/message
ns2:stackTrace
ns2:frame
class=com.sun.xml.ws.message.AbstractMessageImpl
file=AbstractMessageImpl.java line=195 method=readAsSOAPMessage/
ns2:frame
class=com.sun.xml.ws.handler.SOAPMessageContextImpl
file=SOAPMessageContextImpl.java line=79 method=getMessage/
ns2:frame
class=com.theirpackage.utils.logging.SOAPLoggingHandler
file=SOAPLoggingHandler.java line=73 method=log/
...
ns2:cause class=org.xml.sax.SAXParseException note=To disable
this feature, set
com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace system
property to false
messageUnexpected end of input block in start
tag#xD;[\n] at [row,col {unknown-source}]: [1,4096]/message
ns2:stackTrace
ns2:frame
class=com.sun.xml.ws.message.stream.StreamMessage
file=StreamMessage.java line=378 method=writePayloadTo/
ns2:frame
class=com.sun.xml.ws.message.stream.StreamMessage
file=StreamMessage.java line=459 method=writeTo/
ns2:frame
class
RE: HTTP/1.1 400 No client certificate chain in this request
Just a weird question:
Are u suing default jboss web service engine or have integrated axis2
engine with its servlet container?
Regards,
Prateek
From: John Bedell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:36 AM
To: axis-user@ws.apache.org
Subject: HTTP/1.1 400 No client certificate chain in this request
Our setup:
We have an Axis2 1.3 web service client hitting a 3rd party web service
running on a JBoss server w/ Apache Coyote. We do not know what
package(s) were used to developer the server-side.
We need to connect via SSL using certificate authentication.
The basic payload of the web service is a series of updates. Our client
code runs once per day, grabs any updates in our system since the last
run, and sends them on to the server's web service. We can have
anywhere from 0 to a few hundred updates to send.
The problem comes with the amount of updates we have to send. If we
only have a few (1-3) everything runs fine. We send our data up, we
authenticate properly and receive a successful return from the server.
At around 4 or 5 updates (depending on the actual amount of data in the
updates) or rather once we cross 4096 bytes in the request body, we
start receiving errors. If we up it a bit more, say 10 or more updates,
we receive a different error. We've done some investigation and found
several suggestions to turn off HTTP Chunking in the request. We've
done that and we still get the error. We've also tried swapping to HTTP
1.0, as well as increasing the maxHttpHeaderSize on the server-side
JBoss Connector. All with no luck. We attempted to use TCPMON to watch
the transactions go across, but when we turned SSL and Certificate
Authentication off (as we understand is needed for TCPMON to work),
everything worked fine.
We do have a local copy of the 3rd party server that we are testing
against and can make configuration changes to Coyote/JBoss if needed for
testing. However, we have no access to the server-side web service
code, other than through decompliation.
Any help or pointers anyone can offer would be greatly appreciated.
Results with 4-5 updates
The header:
2008/11/18 16:33:58:081 EST [DEBUG] header - HTTP/1.1 500 Internal
Server Error[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Server:
Apache-Coyote/1.1[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - X-Powered-By: Servlet
2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA
date=200710221139)/Tomcat-5.5
[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Content-Type:
text/xml;charset=utf-8[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Transfer-Encoding:
chunked[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Date: Tue, 18 Nov 2008
21:32:38 GMT[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Connection:
close[\r][\n]
The body:
S:Fault xmlns:ns4=http://www.w3.org/2003/05/soap-envelope;
faultcodeS:Server/faultcode
faultstringjavax.xml.soap.SOAPException:
com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block in
start tag#xD;[\n] at [row,col {unknown-source}]: [1,4096]/faultstring
detail
ns2:exception xmlns:ns2=http://jax-ws.dev.java.net/;
class=javax.xml.ws.WebServiceException note=To disable this feature,
set com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace
system property to false
messagejavax.xml.soap.SOAPException:
com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block in
start tag#xD;[\n] at [row,col {unknown-source}]: [1,4096]/message
ns2:stackTracens2:frame
class=com.sun.xml.ws.handler.SOAPMessageContextImpl
file=SOAPMessageContextImpl.java line=81 method=getMessage/
ns2:frame
class=com.theirpackage.utils.logging.SOAPLoggingHandler
file=SOAPLoggingHandler.java line=73 method=log/
...
ns2:cause class=javax.xml.soap.SOAPException note=To disable
this feature, set
com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace system
property to false
messagecom.ctc.wstx.exc.WstxEOFException: Unexpected end
of input block in start tag#xD;[\n] at [row,col {unknown-source}]:
[1,4096]/message
ns2:stackTrace
ns2:frame
class=com.sun.xml.ws.message.AbstractMessageImpl
file=AbstractMessageImpl.java line=195 method=readAsSOAPMessage/
ns2:frame
class=com.sun.xml.ws.handler.SOAPMessageContextImpl
file=SOAPMessageContextImpl.java line=79 method=getMessage/
ns2:frame
class=com.theirpackage.utils.logging.SOAPLoggingHandler
file=SOAPLoggingHandler.java line=73 method=log/
...
ns2:cause class=org.xml.sax.SAXParseException note=To disable
this feature, set
com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace system
property to false
messageUnexpected end of input block in start
tag#xD;[\n] at [row,col {unknown-source
RE: HTTP/1.1 400 No client certificate chain in this request
I'm not entirely sure. But I don't see any Axiss JARs included in the
package they sent for running the JBoss server, so I doubt they are
using it.
John
From: Jain, Prateek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:48 AM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
Just a weird question:
Are u suing default jboss web service engine or have integrated axis2
engine with its servlet container?
Regards,
Prateek
From: John Bedell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:36 AM
To: axis-user@ws.apache.org
Subject: HTTP/1.1 400 No client certificate chain in this request
Our setup:
We have an Axis2 1.3 web service client hitting a 3rd party web service
running on a JBoss server w/ Apache Coyote. We do not know what
package(s) were used to developer the server-side.
We need to connect via SSL using certificate authentication.
The basic payload of the web service is a series of updates. Our client
code runs once per day, grabs any updates in our system since the last
run, and sends them on to the server's web service. We can have
anywhere from 0 to a few hundred updates to send.
The problem comes with the amount of updates we have to send. If we
only have a few (1-3) everything runs fine. We send our data up, we
authenticate properly and receive a successful return from the server.
At around 4 or 5 updates (depending on the actual amount of data in the
updates) or rather once we cross 4096 bytes in the request body, we
start receiving errors. If we up it a bit more, say 10 or more updates,
we receive a different error. We've done some investigation and found
several suggestions to turn off HTTP Chunking in the request. We've
done that and we still get the error. We've also tried swapping to HTTP
1.0, as well as increasing the maxHttpHeaderSize on the server-side
JBoss Connector. All with no luck. We attempted to use TCPMON to watch
the transactions go across, but when we turned SSL and Certificate
Authentication off (as we understand is needed for TCPMON to work),
everything worked fine.
We do have a local copy of the 3rd party server that we are testing
against and can make configuration changes to Coyote/JBoss if needed for
testing. However, we have no access to the server-side web service
code, other than through decompliation.
Any help or pointers anyone can offer would be greatly appreciated.
Results with 4-5 updates
The header:
2008/11/18 16:33:58:081 EST [DEBUG] header - HTTP/1.1 500 Internal
Server Error[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Server:
Apache-Coyote/1.1[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - X-Powered-By: Servlet
2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA
date=200710221139)/Tomcat-5.5
[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Content-Type:
text/xml;charset=utf-8[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Transfer-Encoding:
chunked[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Date: Tue, 18 Nov 2008
21:32:38 GMT[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Connection:
close[\r][\n]
The body:
S:Fault xmlns:ns4=http://www.w3.org/2003/05/soap-envelope;
faultcodeS:Server/faultcode
faultstringjavax.xml.soap.SOAPException:
com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block in
start tag#xD;[\n] at [row,col {unknown-source}]: [1,4096]/faultstring
detail
ns2:exception xmlns:ns2=http://jax-ws.dev.java.net/;
class=javax.xml.ws.WebServiceException note=To disable this feature,
set com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace
system property to false
messagejavax.xml.soap.SOAPException:
com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block in
start tag#xD;[\n] at [row,col {unknown-source}]: [1,4096]/message
ns2:stackTracens2:frame
class=com.sun.xml.ws.handler.SOAPMessageContextImpl
file=SOAPMessageContextImpl.java line=81 method=getMessage/
ns2:frame
class=com.theirpackage.utils.logging.SOAPLoggingHandler
file=SOAPLoggingHandler.java line=73 method=log/
...
ns2:cause class=javax.xml.soap.SOAPException note=To disable
this feature, set
com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace system
property to false
messagecom.ctc.wstx.exc.WstxEOFException: Unexpected end
of input block in start tag#xD;[\n] at [row,col {unknown-source}]:
[1,4096]/message
ns2:stackTrace
ns2:frame
class=com.sun.xml.ws.message.AbstractMessageImpl
file=AbstractMessageImpl.java line=195 method=readAsSOAPMessage/
ns2:frame
class=com.sun.xml.ws.handler.SOAPMessageContextImpl
file=SOAPMessageContextImpl.java line=79 method=getMessage/
ns2:frame
class
RE: HTTP/1.1 400 No client certificate chain in this request
Try removing default jboss WS implementation and integrating/using AXIS2
engine. Hope, it works for u guys.
Regards,
Prateek
From: John Bedell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:58 AM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
I'm not entirely sure. But I don't see any Axiss JARs included in the
package they sent for running the JBoss server, so I doubt they are
using it.
John
From: Jain, Prateek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:48 AM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
Just a weird question:
Are u suing default jboss web service engine or have integrated axis2
engine with its servlet container?
Regards,
Prateek
From: John Bedell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:36 AM
To: axis-user@ws.apache.org
Subject: HTTP/1.1 400 No client certificate chain in this request
Our setup:
We have an Axis2 1.3 web service client hitting a 3rd party web service
running on a JBoss server w/ Apache Coyote. We do not know what
package(s) were used to developer the server-side.
We need to connect via SSL using certificate authentication.
The basic payload of the web service is a series of updates. Our client
code runs once per day, grabs any updates in our system since the last
run, and sends them on to the server's web service. We can have
anywhere from 0 to a few hundred updates to send.
The problem comes with the amount of updates we have to send. If we
only have a few (1-3) everything runs fine. We send our data up, we
authenticate properly and receive a successful return from the server.
At around 4 or 5 updates (depending on the actual amount of data in the
updates) or rather once we cross 4096 bytes in the request body, we
start receiving errors. If we up it a bit more, say 10 or more updates,
we receive a different error. We've done some investigation and found
several suggestions to turn off HTTP Chunking in the request. We've
done that and we still get the error. We've also tried swapping to HTTP
1.0, as well as increasing the maxHttpHeaderSize on the server-side
JBoss Connector. All with no luck. We attempted to use TCPMON to watch
the transactions go across, but when we turned SSL and Certificate
Authentication off (as we understand is needed for TCPMON to work),
everything worked fine.
We do have a local copy of the 3rd party server that we are testing
against and can make configuration changes to Coyote/JBoss if needed for
testing. However, we have no access to the server-side web service
code, other than through decompliation.
Any help or pointers anyone can offer would be greatly appreciated.
Results with 4-5 updates
The header:
2008/11/18 16:33:58:081 EST [DEBUG] header - HTTP/1.1 500 Internal
Server Error[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Server:
Apache-Coyote/1.1[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - X-Powered-By: Servlet
2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA
date=200710221139)/Tomcat-5.5
[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Content-Type:
text/xml;charset=utf-8[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Transfer-Encoding:
chunked[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Date: Tue, 18 Nov 2008
21:32:38 GMT[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Connection:
close[\r][\n]
The body:
S:Fault xmlns:ns4=http://www.w3.org/2003/05/soap-envelope;
faultcodeS:Server/faultcode
faultstringjavax.xml.soap.SOAPException:
com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block in
start tag#xD;[\n] at [row,col {unknown-source}]: [1,4096]/faultstring
detail
ns2:exception xmlns:ns2=http://jax-ws.dev.java.net/;
class=javax.xml.ws.WebServiceException note=To disable this feature,
set com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace
system property to false
messagejavax.xml.soap.SOAPException:
com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block in
start tag#xD;[\n] at [row,col {unknown-source}]: [1,4096]/message
ns2:stackTracens2:frame
class=com.sun.xml.ws.handler.SOAPMessageContextImpl
file=SOAPMessageContextImpl.java line=81 method=getMessage/
ns2:frame
class=com.theirpackage.utils.logging.SOAPLoggingHandler
file=SOAPLoggingHandler.java line=73 method=log/
...
ns2:cause class=javax.xml.soap.SOAPException note=To disable
this feature, set
com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace system
property to false
messagecom.ctc.wstx.exc.WstxEOFException: Unexpected end
of input block in start tag#xD;[\n] at [row,col {unknown-source}]:
[1,4096]/message
RE: HTTP/1.1 400 No client certificate chain in this request
I would love to try that, but the server-side component belongs to a 3rd
party and we have no control over how they implement their end.
John
From: Jain, Prateek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 12:02 PM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
Try removing default jboss WS implementation and integrating/using AXIS2
engine. Hope, it works for u guys.
Regards,
Prateek
From: John Bedell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:58 AM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
I'm not entirely sure. But I don't see any Axiss JARs included in the
package they sent for running the JBoss server, so I doubt they are
using it.
John
From: Jain, Prateek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:48 AM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
Just a weird question:
Are u suing default jboss web service engine or have integrated axis2
engine with its servlet container?
Regards,
Prateek
From: John Bedell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:36 AM
To: axis-user@ws.apache.org
Subject: HTTP/1.1 400 No client certificate chain in this request
Our setup:
We have an Axis2 1.3 web service client hitting a 3rd party web service
running on a JBoss server w/ Apache Coyote. We do not know what
package(s) were used to developer the server-side.
We need to connect via SSL using certificate authentication.
The basic payload of the web service is a series of updates. Our client
code runs once per day, grabs any updates in our system since the last
run, and sends them on to the server's web service. We can have
anywhere from 0 to a few hundred updates to send.
The problem comes with the amount of updates we have to send. If we
only have a few (1-3) everything runs fine. We send our data up, we
authenticate properly and receive a successful return from the server.
At around 4 or 5 updates (depending on the actual amount of data in the
updates) or rather once we cross 4096 bytes in the request body, we
start receiving errors. If we up it a bit more, say 10 or more updates,
we receive a different error. We've done some investigation and found
several suggestions to turn off HTTP Chunking in the request. We've
done that and we still get the error. We've also tried swapping to HTTP
1.0, as well as increasing the maxHttpHeaderSize on the server-side
JBoss Connector. All with no luck. We attempted to use TCPMON to watch
the transactions go across, but when we turned SSL and Certificate
Authentication off (as we understand is needed for TCPMON to work),
everything worked fine.
We do have a local copy of the 3rd party server that we are testing
against and can make configuration changes to Coyote/JBoss if needed for
testing. However, we have no access to the server-side web service
code, other than through decompliation.
Any help or pointers anyone can offer would be greatly appreciated.
Results with 4-5 updates
The header:
2008/11/18 16:33:58:081 EST [DEBUG] header - HTTP/1.1 500 Internal
Server Error[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Server:
Apache-Coyote/1.1[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - X-Powered-By: Servlet
2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA
date=200710221139)/Tomcat-5.5
[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Content-Type:
text/xml;charset=utf-8[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Transfer-Encoding:
chunked[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Date: Tue, 18 Nov 2008
21:32:38 GMT[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Connection:
close[\r][\n]
The body:
S:Fault xmlns:ns4=http://www.w3.org/2003/05/soap-envelope;
faultcodeS:Server/faultcode
faultstringjavax.xml.soap.SOAPException:
com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block in
start tag#xD;[\n] at [row,col {unknown-source}]: [1,4096]/faultstring
detail
ns2:exception xmlns:ns2=http://jax-ws.dev.java.net/;
class=javax.xml.ws.WebServiceException note=To disable this feature,
set com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace
system property to false
messagejavax.xml.soap.SOAPException:
com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block in
start tag#xD;[\n] at [row,col {unknown-source}]: [1,4096]/message
ns2:stackTracens2:frame
class=com.sun.xml.ws.handler.SOAPMessageContextImpl
file=SOAPMessageContextImpl.java line=81 method=getMessage/
ns2:frame
class=com.theirpackage.utils.logging.SOAPLoggingHandler
file
RE: HTTP/1.1 400 No client certificate chain in this request
Ouch! I mean how r u accessing that WS?
Prateek
From: John Bedell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 12:39 PM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
I would love to try that, but the server-side component belongs to a 3rd
party and we have no control over how they implement their end.
John
From: Jain, Prateek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 12:02 PM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
Try removing default jboss WS implementation and integrating/using AXIS2
engine. Hope, it works for u guys.
Regards,
Prateek
From: John Bedell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:58 AM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
I'm not entirely sure. But I don't see any Axiss JARs included in the
package they sent for running the JBoss server, so I doubt they are
using it.
John
From: Jain, Prateek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:48 AM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
Just a weird question:
Are u suing default jboss web service engine or have integrated axis2
engine with its servlet container?
Regards,
Prateek
From: John Bedell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:36 AM
To: axis-user@ws.apache.org
Subject: HTTP/1.1 400 No client certificate chain in this request
Our setup:
We have an Axis2 1.3 web service client hitting a 3rd party web service
running on a JBoss server w/ Apache Coyote. We do not know what
package(s) were used to developer the server-side.
We need to connect via SSL using certificate authentication.
The basic payload of the web service is a series of updates. Our client
code runs once per day, grabs any updates in our system since the last
run, and sends them on to the server's web service. We can have
anywhere from 0 to a few hundred updates to send.
The problem comes with the amount of updates we have to send. If we
only have a few (1-3) everything runs fine. We send our data up, we
authenticate properly and receive a successful return from the server.
At around 4 or 5 updates (depending on the actual amount of data in the
updates) or rather once we cross 4096 bytes in the request body, we
start receiving errors. If we up it a bit more, say 10 or more updates,
we receive a different error. We've done some investigation and found
several suggestions to turn off HTTP Chunking in the request. We've
done that and we still get the error. We've also tried swapping to HTTP
1.0, as well as increasing the maxHttpHeaderSize on the server-side
JBoss Connector. All with no luck. We attempted to use TCPMON to watch
the transactions go across, but when we turned SSL and Certificate
Authentication off (as we understand is needed for TCPMON to work),
everything worked fine.
We do have a local copy of the 3rd party server that we are testing
against and can make configuration changes to Coyote/JBoss if needed for
testing. However, we have no access to the server-side web service
code, other than through decompliation.
Any help or pointers anyone can offer would be greatly appreciated.
Results with 4-5 updates
The header:
2008/11/18 16:33:58:081 EST [DEBUG] header - HTTP/1.1 500 Internal
Server Error[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Server:
Apache-Coyote/1.1[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - X-Powered-By: Servlet
2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA
date=200710221139)/Tomcat-5.5
[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Content-Type:
text/xml;charset=utf-8[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Transfer-Encoding:
chunked[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Date: Tue, 18 Nov 2008
21:32:38 GMT[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Connection:
close[\r][\n]
The body:
S:Fault xmlns:ns4=http://www.w3.org/2003/05/soap-envelope;
faultcodeS:Server/faultcode
faultstringjavax.xml.soap.SOAPException:
com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block in
start tag#xD;[\n] at [row,col {unknown-source}]: [1,4096]/faultstring
detail
ns2:exception xmlns:ns2=http://jax-ws.dev.java.net/;
class=javax.xml.ws.WebServiceException note=To disable this feature,
set com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace
system property to false
messagejavax.xml.soap.SOAPException:
com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block in
start tag#xD;[\n] at [row,col
RE: HTTP/1.1 400 No client certificate chain in this request
We are already using Axis2 on the client side. The production version
will be running under a WebLogic server using Axis2, but we have
reproduced the same problem using a standalone web service client using
Axis2 as well.
We have tried Axis2 1.3 and 1.4 on the client side, both produce the
same results.
I've included the part of our ant script that generates the stubs below,
if that contains what you were asking about.
java
classname=org.apache.axis2.wsdl.WSDL2Java
failonerror=true
arg value=-o/
arg file=${basedir}/
arg value=-t/
arg value=--noBuildXML/
arg value=-s/
arg value=-or/
arg value=-uri/
arg file=${siad_ws_wsdl}/
classpath
path refid=classpath.lib.dir/
pathelement location=${build.classes.dir}/
/classpath
/java
John Bedell
From: Jain, Prateek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 12:46 PM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
Ouch! I mean how r u accessing that WS?
Prateek
From: John Bedell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 12:39 PM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
I would love to try that, but the server-side component belongs to a 3rd
party and we have no control over how they implement their end.
John
From: Jain, Prateek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 12:02 PM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
Try removing default jboss WS implementation and integrating/using AXIS2
engine. Hope, it works for u guys.
Regards,
Prateek
From: John Bedell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:58 AM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
I'm not entirely sure. But I don't see any Axiss JARs included in the
package they sent for running the JBoss server, so I doubt they are
using it.
John
From: Jain, Prateek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:48 AM
To: axis-user@ws.apache.org
Subject: RE: HTTP/1.1 400 No client certificate chain in this request
Just a weird question:
Are u suing default jboss web service engine or have integrated axis2
engine with its servlet container?
Regards,
Prateek
From: John Bedell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 11:36 AM
To: axis-user@ws.apache.org
Subject: HTTP/1.1 400 No client certificate chain in this request
Our setup:
We have an Axis2 1.3 web service client hitting a 3rd party web service
running on a JBoss server w/ Apache Coyote. We do not know what
package(s) were used to developer the server-side.
We need to connect via SSL using certificate authentication.
The basic payload of the web service is a series of updates. Our client
code runs once per day, grabs any updates in our system since the last
run, and sends them on to the server's web service. We can have
anywhere from 0 to a few hundred updates to send.
The problem comes with the amount of updates we have to send. If we
only have a few (1-3) everything runs fine. We send our data up, we
authenticate properly and receive a successful return from the server.
At around 4 or 5 updates (depending on the actual amount of data in the
updates) or rather once we cross 4096 bytes in the request body, we
start receiving errors. If we up it a bit more, say 10 or more updates,
we receive a different error. We've done some investigation and found
several suggestions to turn off HTTP Chunking in the request. We've
done that and we still get the error. We've also tried swapping to HTTP
1.0, as well as increasing the maxHttpHeaderSize on the server-side
JBoss Connector. All with no luck. We attempted to use TCPMON to watch
the transactions go across, but when we turned SSL and Certificate
Authentication off (as we understand is needed for TCPMON to work),
everything worked fine.
We do have a local copy of the 3rd party server that we are testing
against and can make configuration changes to Coyote/JBoss if needed for
testing. However, we have no access to the server-side web service
code, other than through decompliation.
Any help or pointers anyone can offer would be greatly appreciated.
Results with 4-5 updates
The header:
2008/11/18 16:33:58:081 EST [DEBUG] header - HTTP/1.1 500 Internal
Server Error[\r][\n]
2008/11/18 16:33:58:081 EST [DEBUG] header - Server:
Apache-Coyote/1.1
Axis2 - Bug with Proxy and HTTP/1.1?
) at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:749) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167) at gov.nist.registry.xdstest2.XdsTest.run(XdsTest.groovy:342) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:95) at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:599) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:904) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740) at org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:773) at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:753) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167) at gov.nist.registry.xdstest2.XdsTest.main(XdsTest.groovy:48) So as you can see, as soon as I specify a proxy, the Axis2 Framework throws an 501-Not Implemented Exception. Strange, isn't it? So I started to google and I got the advice to use HTTP/1.0 instead of HTTP/1.1 and set the transfer-encoding from chunked to false. (See here for details: http://archives.devshed.com/forums/apache-92/axis2-http-proxy-setting-1846399.html http://archives.devshed.com/forums/apache-92/axis2-http-proxy-setting-1846399.html ) So I tried this and voila - it worked! But my question is very simple. Why does Axis2 does not work when HTTP/1.1 and a proxy is used? Where is the problem? How can I use a proxy and HTTP/1.1? Thanks in Advance for both your time and your knowledge! Greetings Stefan -- View this message in context: http://www.nabble.com/Axis2---Bug-with-Proxy-and-HTTP-1.1--tp20497611p20497611.html Sent from the Axis - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 - Bug with Proxy and HTTP/1.1?
Stefan Its not the Axis2 client reporting Not Implemented. Its either the proxy or the server (Hard to tell which without seeing a wire trace or the logs from those systems). I'm guessing its the proxy. Axis2 is sending the message successfully and its the other system that can't handle HTTP 1.1. Paul On Fri, Nov 14, 2008 at 9:59 AM, StrongSteve [EMAIL PROTECTED] wrote: Hi Everybody! Recently I have stumbled across a curious behavior of the Axis2 Framework. As I am not sure whether I am doing something wrong or if it is a bug, I try to outline my experience. Perhaps someone has made the same experiences. Basically I have an application, that uses the Axis2 Framework to contact a web service. So it can be seen as kind of a web service client. As I am working behind a companies proxy server, I added my proxy setting to the startup of the program, as usual. This looks something like: java -Dhttp.proxyHost=MyProxyhost -Dhttp.proxyPort=MyProxyPort -Dhttp.nonProxyHosts=MyExcludedHosts gov.nist.registry.xdstest2.XdsTest $* Funny thing, the program finished with the following stacktrace (only an extract): Transport error: 501 Error: Not Implemented org.apache.axis2.AxisFault: Transport error: 501 Error: Not Implemented at org.apache.axis2.transport.http.HTTPSender.handleResponse(HTTPSender.java:296) at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:190) at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:371) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:209) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:401) at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228) at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163) at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:548) at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:528) at gov.nist.registry.common2.registry.Soap.soapCall(Soap.java:60) at gov.nist.registry.xdstest2.StoredQueryTransaction.runSQ(StoredQueryTransaction.java:99) at gov.nist.registry.xdstest2.StoredQueryTransaction.run(StoredQueryTransaction.java:41) at gov.nist.registry.xdstest2.StepContext.run(StepContext.java:153) at gov.nist.registry.xdstest2.PlanContext.run(PlanContext.java:138) at gov.nist.registry.xdstest2.Xdstest2.runTest(Xdstest2.java:263) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:95) at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:599) at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1077) at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:744) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167) at gov.nist.registry.xdstest2.XdsTest$_run_closure6.doCall(XdsTest.groovy:353) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:95) at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:599) at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:252) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740) at groovy.lang.Closure.call(Closure.java:292) at groovy.lang.Closure.call(Closure.java:305) at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:990) at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:967) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:51
Re: Axis2 - Bug with Proxy and HTTP/1.1?
Hi Paul, Thanks for your quick reply. So it could be, that our proxy server does not support HTTP/1.1 - or to be specific Chunking and returns this error message back to the caller - me. That is indeed a great tip. I will check with our network guys on Monday! Thanks again! Greetings Stefan pzfreo wrote: Stefan Its not the Axis2 client reporting Not Implemented. Its either the proxy or the server (Hard to tell which without seeing a wire trace or the logs from those systems). I'm guessing its the proxy. Axis2 is sending the message successfully and its the other system that can't handle HTTP 1.1. Paul On Fri, Nov 14, 2008 at 9:59 AM, StrongSteve [EMAIL PROTECTED] wrote: Hi Everybody! Recently I have stumbled across a curious behavior of the Axis2 Framework. As I am not sure whether I am doing something wrong or if it is a bug, I try to outline my experience. Perhaps someone has made the same experiences. Basically I have an application, that uses the Axis2 Framework to contact a web service. So it can be seen as kind of a web service client. As I am working behind a companies proxy server, I added my proxy setting to the startup of the program, as usual. This looks something like: java -Dhttp.proxyHost=MyProxyhost -Dhttp.proxyPort=MyProxyPort -Dhttp.nonProxyHosts=MyExcludedHosts gov.nist.registry.xdstest2.XdsTest $* Funny thing, the program finished with the following stacktrace (only an extract): Transport error: 501 Error: Not Implemented org.apache.axis2.AxisFault: Transport error: 501 Error: Not Implemented at org.apache.axis2.transport.http.HTTPSender.handleResponse(HTTPSender.java:296) at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:190) at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:371) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:209) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:401) at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228) at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163) at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:548) at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:528) at gov.nist.registry.common2.registry.Soap.soapCall(Soap.java:60) at gov.nist.registry.xdstest2.StoredQueryTransaction.runSQ(StoredQueryTransaction.java:99) at gov.nist.registry.xdstest2.StoredQueryTransaction.run(StoredQueryTransaction.java:41) at gov.nist.registry.xdstest2.StepContext.run(StepContext.java:153) at gov.nist.registry.xdstest2.PlanContext.run(PlanContext.java:138) at gov.nist.registry.xdstest2.Xdstest2.runTest(Xdstest2.java:263) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:95) at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:599) at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1077) at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:744) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167) at gov.nist.registry.xdstest2.XdsTest$_run_closure6.doCall(XdsTest.groovy:353) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:95) at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:599) at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:252) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740) at groovy.lang.Closure.call(Closure.java:292) at groovy.lang.Closure.call(Closure.java:305) at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:990) at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:967) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method
http 1.1 chunking and large messages using axis2 1.3
Hello All, I am wondering how large message (lets say 0,5GB) are handled when it is sent chunked over HTTP 1.1 and there is a network interruption. Does it support some kind of restarts, allowing the transfer to continue where it left off if it is interrupted, rather than starting over from the beginning? Thanks in advance. Kind regards, Erwin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http 1.1 chunking and large messages using axis2 1.3
On Dec 20, 2007 2:44 PM, Erwin Reinhoud [EMAIL PROTECTED] wrote: Hello All, I am wondering how large message (lets say 0,5GB) are handled when it is sent chunked over HTTP 1.1 and there is a network interruption. Does it support some kind of restarts, allowing the transfer to continue where it left off if it is interrupted, rather than starting over from the beginning? Hi, I don't know about axis2 if it has this kind of support, but I know what you could do if something like this happens. On the on end you could keep a count on how many bytes were received. When the connection cuts the client requests to resume, you send it the number of bytes -5 (or something) and you continue sending the file starting from that position. Essentialy it's the same resume feature ftp has. But it would be cool if there is something like this inherently in axis2 (but I doubt unless an axis2 dev replies) Thanks in advance. Kind regards, Erwin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nothing is impossible for the person that doesn't have to do it The probability of anything happening is in inverse ratio to its desirability The problem is not freedom of choice, it is about the choices you have. Choice is always limited by the number of alternatives presented to you -- George H [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis 1.4 configuration to use HTTP/1.1
Hello Shadab! Sorry I was not able to reply to this until now. I was trying to set the configuration of the client-side transport to utilize CommonsHTTPSender via settings on the Call object. That was not working. Jeff had given me some alternatives to try, such as setting the properties on the client-side EngineConfiguration. Unfortunately, I have not had the chance to try that yet as another project took precedence. Hopefully I can try that out later today or tomorrow and get back to the list with my results. Were you able to make some progress on this front in a different direction? Thanks! Mario- - Original Message From: Shadab [EMAIL PROTECTED] To: axis-user@ws.apache.org Sent: Wednesday, October 3, 2007 2:36:50 AM Subject: Axis 1.4 configuration to use HTTP/1.1 Hi All, Please let me know if there is any way to configure Axis1.4 such that it uses HTTP/1.1 instead of HTTP/1.0 The request from the soapclient (implemented using service stub) lands with Axis/1.4 which in turn by default presumably uses HTTP/1.0. Can't this be changed somehow using CommonsHTTPSender as pointed by mail thread of Mario/Jeff Axis 1.4 CommonsHTTPSender question Date Sep:20:2007 ? Mario/Jeff, Please let me know if you people have reached some solution and will that solution be helpful in the scenario I have told above... Thanks, Shadab -- View this message in context: http://www.nabble.com/Axis-1.4-configuration-to-use-HTTP-1.1-tf4560281.html#a13014221 Sent from the Axis - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Axis 1.4 configuration to use HTTP/1.1
Hi Mario, Shadab got his problem solved. (He wanted to use HTTP 1.1 in Axis 1.4 and do it programmmatically on the clientside). the solution he emailed to me is: Hi Jeff, Thank you so much for all the info.. I have succesfully implemented the second alternative of using - CommonsHTTPSender as the Transport Sender of the axis client, viz., BasicClientConfig basicClientConfig = new BasicClientConfig(); SimpleChain simpleChain = new SimpleChain(); simpleChain.addHandler(new CommonsHTTPSender()); basicClientConfig.deployTransport(http, simpleChain); LogonService_Service logonService = new LogonService_ServiceLocator(basicClientConfig); and in the server-config.wsdd I added the pivot=java:org.apache.axis.transport.http.CommonsHTTPSender Cheers, Shadab But your issue is the three requests, where one is in http 1.0 and the other two are http 1.1. Correct? If so, I still think you are registering two handlers (that use CommonsSender and hence http 1.1) and the default HTTPSender is called in the middle to send it using HTTP 1.0. If that is also true, then the programmatic registering of the two handlers is incorrect. -jeff _ From: Mario Felarca [mailto:[EMAIL PROTECTED] Sent: Monday, October 08, 2007 11:56 AM To: axis-user@ws.apache.org Subject: Re: Axis 1.4 configuration to use HTTP/1.1 Hello Shadab! Sorry I was not able to reply to this until now. I was trying to set the configuration of the client-side transport to utilize CommonsHTTPSender via settings on the Call object. That was not working. Jeff had given me some alternatives to try, such as setting the properties on the client-side EngineConfiguration. Unfortunately, I have not had the chance to try that yet as another project took precedence. Hopefully I can try that out later today or tomorrow and get back to the list with my results. Were you able to make some progress on this front in a different direction? Thanks! Mario- - Original Message From: Shadab [EMAIL PROTECTED] To: axis-user@ws.apache.org Sent: Wednesday, October 3, 2007 2:36:50 AM Subject: Axis 1.4 configuration to use HTTP/1.1 Hi All, Please let me know if there is any way to configure Axis1.4 such that it uses HTTP/1.1 instead of HTTP/1.0 The request from the soapclient (implemented using service stub) lands with Axis/1.4 which in turn by default presumably uses HTTP/1.0. Can't this be changed somehow using CommonsHTTPSender as pointed by mail thread of Mario/Jeff Axis 1.4 CommonsHTTPSender question Date Sep:20:2007 ? Mario/Jeff, Please let me know if you people have reached some solution and will that solution be helpful in the scenario I have told above... Thanks, Shadab -- View this message in context: http://www.nabble.com/Axis-1.4-configuration-to-use-HTTP-1.1-tf4560281.h tml#a13014221 Sent from the Axis - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis 1.4 configuration to use HTTP/1.1
Hello Jeff!
Thank you for the information. This seems similar conceptually to the direction
you were pointing me in earlier, correct? I'll give it a shot. You are correct,
the other issue I had was the 3 requests instead of one, however you may be
right that the issues were related. I'll make this change first and go from
there.
Thanks again for the help!
Mario-
- Original Message
From: Walker, Jeff [EMAIL PROTECTED]
To: axis-user@ws.apache.org
Sent: Monday, October 8, 2007 11:27:23 AM
Subject: RE: Axis 1.4 configuration to use HTTP/1.1
DIV {
MARGIN:0px;}
Hi Mario,
Shadab got his problem solved. (He
wanted to use HTTP 1.1 in Axis 1.4 and do it programmmatically on the
clientside). the solution he emailed to me
is:
Hi Jeff,
Thank you so much for all the
info..
I have succesfully implemented the second
alternative of using - CommonsHTTPSender as the Transport Sender of the axis
client, viz.,
BasicClientConfig basicClientConfig =
new BasicClientConfig();
SimpleChain simpleChain = new
SimpleChain();
simpleChain.addHandler(new
CommonsHTTPSender());
basicClientConfig.deployTransport(http,
simpleChain);
LogonService_Service logonService =
new
LogonService_ServiceLocator(basicClientConfig);
and in the server-config.wsdd I added
the
pivot=java:org.apache.axis.transport.http.CommonsHTTPSender
Cheers,
Shadab
But your issue is the three requests,
where one is in http 1.0 and the other two are http 1.1.
Correct?
If so, I still
think you are registering two handlers (that use CommonsSender and hence
http 1.1) and the default HTTPSender is
called in the middle to send it using HTTP 1.0.
If that is also true, then the programmatic registering of the two handlers is
incorrect.
-jeff
From: Mario Felarca
[mailto:[EMAIL PROTECTED]
Sent: Monday, October 08, 2007 11:56
AM
To: axis-user@ws.apache.org
Subject: Re: Axis 1.4
configuration to use HTTP/1.1
Hello
Shadab!
Sorry I was not able to reply to this until now. I was trying
to set the configuration of the client-side transport to utilize
CommonsHTTPSender via settings on the Call object. That was not working. Jeff
had given me some alternatives to try, such as setting the properties on the
client-side EngineConfiguration. Unfortunately, I have not had the chance to
try that yet as another project took precedence. Hopefully I can try that out
later today or tomorrow and get back to the list with my results.
Were
you able to make some progress on this front in a different
direction?
Thanks!
Mario-
-
Original Message
From: Shadab [EMAIL PROTECTED]
To:
axis-user@ws.apache.org
Sent: Wednesday, October 3, 2007 2:36:50
AM
Subject: Axis 1.4 configuration to use HTTP/1.1
Hi All,
Please let me know if there is any way to configure
Axis1.4 such that it
uses HTTP/1.1 instead of HTTP/1.0
The request
from the soapclient (implemented using service stub) lands with
Axis/1.4
which in turn by default presumably uses HTTP/1.0.
Can't this be
changed somehow using CommonsHTTPSender as pointed by mail
thread of
Mario/Jeff Axis 1.4 CommonsHTTPSender question Date
Sep:20:2007
?
Mario/Jeff,
Please let me know if you people have
reached some solution and will that
solution be helpful in the scenario I
have told above...
Thanks,
Shadab
--
View this message in
context:
http://www.nabble.com/Axis-1.4-configuration-to-use-HTTP-1.1-tf4560281.html#a13014221
Sent
from the Axis - User mailing list archive at
Nabble.com.
-
To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
commands, e-mail:
[EMAIL PROTECTED]
Re: Axis 1.4 configuration to use HTTP/1.1
Hello again Jeff!
That did the trick. The configuration I was trying to set on the Call object
directly before was incorrect and was causing the multiple requests and the
incorrect transport of the actual call.
I appreciate the help with this, and thanks to Shadab as well!
Mario-
- Original Message
From: Walker, Jeff [EMAIL PROTECTED]
To: axis-user@ws.apache.org
Sent: Monday, October 8, 2007 11:27:23 AM
Subject: RE: Axis 1.4 configuration to use HTTP/1.1
DIV {
MARGIN:0px;}
Hi Mario,
Shadab got his problem solved. (He
wanted to use HTTP 1.1 in Axis 1.4 and do it programmmatically on the
clientside). the solution he emailed to me
is:
Hi Jeff,
Thank you so much for all the
info..
I have succesfully implemented the second
alternative of using - CommonsHTTPSender as the Transport Sender of the axis
client, viz.,
BasicClientConfig basicClientConfig =
new BasicClientConfig();
SimpleChain simpleChain = new
SimpleChain();
simpleChain.addHandler(new
CommonsHTTPSender());
basicClientConfig.deployTransport(http,
simpleChain);
LogonService_Service logonService =
new
LogonService_ServiceLocator(basicClientConfig);
and in the server-config.wsdd I added
the
pivot=java:org.apache.axis.transport.http.CommonsHTTPSender
Cheers,
Shadab
But your issue is the three requests,
where one is in http 1.0 and the other two are http 1.1.
Correct?
If so, I still
think you are registering two handlers (that use CommonsSender and hence
http 1.1) and the default HTTPSender is
called in the middle to send it using HTTP 1.0.
If that is also true, then the programmatic registering of the two handlers is
incorrect.
-jeff
From: Mario Felarca
[mailto:[EMAIL PROTECTED]
Sent: Monday, October 08, 2007 11:56
AM
To: axis-user@ws.apache.org
Subject: Re: Axis 1.4
configuration to use HTTP/1.1
Hello
Shadab!
Sorry I was not able to reply to this until now. I was trying
to set the configuration of the client-side transport to utilize
CommonsHTTPSender via settings on the Call object. That was not working. Jeff
had given me some alternatives to try, such as setting the properties on the
client-side EngineConfiguration. Unfortunately, I have not had the chance to
try that yet as another project took precedence. Hopefully I can try that out
later today or tomorrow and get back to the list with my results.
Were
you able to make some progress on this front in a different
direction?
Thanks!
Mario-
-
Original Message
From: Shadab [EMAIL PROTECTED]
To:
axis-user@ws.apache.org
Sent: Wednesday, October 3, 2007 2:36:50
AM
Subject: Axis 1.4 configuration to use HTTP/1.1
Hi All,
Please let me know if there is any way to configure
Axis1.4 such that it
uses HTTP/1.1 instead of HTTP/1.0
The request
from the soapclient (implemented using service stub) lands with
Axis/1.4
which in turn by default presumably uses HTTP/1.0.
Can't this be
changed somehow using CommonsHTTPSender as pointed by mail
thread of
Mario/Jeff Axis 1.4 CommonsHTTPSender question Date
Sep:20:2007
?
Mario/Jeff,
Please let me know if you people have
reached some solution and will that
solution be helpful in the scenario I
have told above...
Thanks,
Shadab
--
View this message in
context:
http://www.nabble.com/Axis-1.4-configuration-to-use-HTTP-1.1-tf4560281.html#a13014221
Sent
from the Axis - User mailing list archive at
Nabble.com.
-
To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
commands, e-mail:
[EMAIL PROTECTED]
Axis 1.4 configuration to use HTTP/1.1
Hi All, Please let me know if there is any way to configure Axis1.4 such that it uses HTTP/1.1 instead of HTTP/1.0 The request from the soapclient (implemented using service stub) lands with Axis/1.4 which in turn by default presumably uses HTTP/1.0. Can't this be changed somehow using CommonsHTTPSender as pointed by mail thread of Mario/Jeff Axis 1.4 CommonsHTTPSender question Date Sep:20:2007 ? Mario/Jeff, Please let me know if you people have reached some solution and will that solution be helpful in the scenario I have told above... Thanks, Shadab -- View this message in context: http://www.nabble.com/Axis-1.4-configuration-to-use-HTTP-1.1-tf4560281.html#a13014221 Sent from the Axis - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Axis 1.4 configuration to use HTTP/1.1
Hi,
So, I tried playing around with the http version. Theoretically, you
should be able to set a property on the binding (or at least, the Call
object) to switch between http 1.0 and http 1.1 This did not work.
I could only manage to change to http 1.1 by editing the method
writeToSocket() in HTTPSender where it says:
String httpver =
msgContext.getStrProp(MessageContext.HTTP_TRANSPORT_VERSION);
if (null == httpver) {
httpver = HTTPConstants.HEADER_PROTOCOL_V10;
}
To
String httpver =
msgContext.getStrProp(MessageContext.HTTP_TRANSPORT_VERSION);
if (null == httpver) {
httpver = HTTPConstants.HEADER_PROTOCOL_V11;
}
Note how all I did was change the httpver variable.
The issue is, you then need to recompile Axis to pick up the change in
HTTPSender. To get around the fact we are supposed to use the binary
distribution and can't recompile Axis, I wrote my own class that extends
HTTPSender and then over rode the writeToSocket() method. I simply cut
and pasted that method in its entirety to the equivalent method in my
class and edited the line I mentioned above. The next step is to make
sure you pick up your sender and not the default HTTPSender. You can do
this by edting the client-config.wsdd file to pick up your class like
this:
Client-config.wsdd:
deployment xmlns=http://xml.apache.org/axis/wsdd/;
xmlns:java=http://xml.apache.org/axis/wsdd/providers/java;
transport name=http
pivot=java:com.company.www.project.FMRHttpSender/
/deployment
Where my class is obviously called FMRHTTPSender.
After all that, it worked.
-
As a much easier alternative, CommonsHTTPSender by default uses http
1.1. So, simply create a client-config.wsdd file and pick up the Commons
sender. Something like this should work:
deployment xmlns=http://xml.apache.org/axis/wsdd/;
xmlns:java=http://xml.apache.org/axis/wsdd/providers/java;
transport name=http
pivot=java:org.apache.axis.transport.http.CommonsHTTPSender/
/deployment
The above commons sender also worked for me.
Cheers,
-jeff
-Original Message-
From: Shadab [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 03, 2007 3:37 AM
To: axis-user@ws.apache.org
Subject: Axis 1.4 configuration to use HTTP/1.1
Hi All,
Please let me know if there is any way to configure Axis1.4 such that it
uses HTTP/1.1 instead of HTTP/1.0
The request from the soapclient (implemented using service stub) lands
with
Axis/1.4 which in turn by default presumably uses HTTP/1.0.
Can't this be changed somehow using CommonsHTTPSender as pointed by mail
thread of Mario/Jeff Axis 1.4 CommonsHTTPSender question Date
Sep:20:2007
?
Mario/Jeff,
Please let me know if you people have reached some solution and will
that
solution be helpful in the scenario I have told above...
Thanks,
Shadab
--
View this message in context:
http://www.nabble.com/Axis-1.4-configuration-to-use-HTTP-1.1-tf4560281.h
tml#a13014221
Sent from the Axis - User mailing list archive at Nabble.com.
-
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]
RE: Axis 1.4 configuration to use HTTP/1.1
Using Commons HTTP client with Axis
By default Apache Axis 1.4 uses 'org.apache.axis.transport.http.HTTPSender'
for http sending.
It is possible to change this to use 'org.apache.commons.httpclient'.
Change the transport pivot attribute in the configuration to point to the
CommonsHTTPSender class.
transport name=http
pivot=java:org.apache.axis.transport.http.CommonsHTTPSender/
The following is an example of an axis client configuration file.
?xml version=1.0 encoding=UTF-8?
deployment name=defaultClientConfig
xmlns=http://xml.apache.org/axis/wsdd/;
xmlns:java=http://xml.apache.org/axis/wsdd/providers/java;
globalConfiguration
parameter name=disablePrettyXML value=true/
parameter name=enableNamespacePrefixOptimization value=false/
/globalConfiguration
transport name=http
pivot=java:org.apache.axis.transport.http.CommonsHTTPSender/
transport name=local
pivot=java:org.apache.axis.transport.local.LocalSender/
transport name=java
pivot=java:org.apache.axis.transport.java.JavaSender/
/deployment
You also need to add the common.codec.1.3.jar and
common-httpclient-3.0-rc4.jar to the jar directory.
http://jakarta.apache.org/commons/
http://jakarta.apache.org/commons/httpclient/
http://jakarta.apache.org/commons/httpclient/features.html
http://jakarta.apache.org/site/downloads/downloads_commons.html
http://jakarta.apache.org/commons/httpclient/logging.html
By default commons http client uses HTTP protocol 1.1 and by default it uses
chunked transfer encoding.
When a HTTP client program sends Transfer-Encoding chunked, it cannot send
Content-Length.
You can also programmatically switch back to HTTP/1.0 by using the following
code.
stub._setProperty ( org.apache.axis.MessageContext.HTTP_TRANSPORT_VERSION ,
org.apache.axis.transport.http.HTTPConstants.HEADER_PROTOCOL_V10);
===
-Original Message-
From: Walker, Jeff [mailto:[EMAIL PROTECTED]
Sent: Thursday, 4 October 2007 2:35 AM
To: axis-user@ws.apache.org
Subject: RE: Axis 1.4 configuration to use HTTP/1.1
Hi,
So, I tried playing around with the http version. Theoretically, you
should be able to set a property on the binding (or at least, the Call
object) to switch between http 1.0 and http 1.1 This did not work.
I could only manage to change to http 1.1 by editing the method
writeToSocket() in HTTPSender where it says:
String httpver =
msgContext.getStrProp(MessageContext.HTTP_TRANSPORT_VERSION);
if (null == httpver) {
httpver = HTTPConstants.HEADER_PROTOCOL_V10;
}
To
String httpver =
msgContext.getStrProp(MessageContext.HTTP_TRANSPORT_VERSION);
if (null == httpver) {
httpver = HTTPConstants.HEADER_PROTOCOL_V11;
}
Note how all I did was change the httpver variable.
The issue is, you then need to recompile Axis to pick up the change in
HTTPSender. To get around the fact we are supposed to use the binary
distribution and can't recompile Axis, I wrote my own class that extends
HTTPSender and then over rode the writeToSocket() method. I simply cut
and pasted that method in its entirety to the equivalent method in my
class and edited the line I mentioned above. The next step is to make
sure you pick up your sender and not the default HTTPSender. You can do
this by edting the client-config.wsdd file to pick up your class like
this:
Client-config.wsdd:
deployment xmlns=http://xml.apache.org/axis/wsdd/;
xmlns:java=http://xml.apache.org/axis/wsdd/providers/java;
transport name=http
pivot=java:com.company.www.project.FMRHttpSender/
/deployment
Where my class is obviously called FMRHTTPSender.
After all that, it worked.
-
As a much easier alternative, CommonsHTTPSender by default uses http
1.1. So, simply create a client-config.wsdd file and pick up the Commons
sender. Something like this should work:
deployment xmlns=http://xml.apache.org/axis/wsdd/;
xmlns:java=http://xml.apache.org/axis/wsdd/providers/java;
transport name=http
pivot=java:org.apache.axis.transport.http.CommonsHTTPSender/
/deployment
The above commons sender also worked for me.
Cheers,
-jeff
-Original Message-
From: Shadab [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 03, 2007 3:37 AM
To: axis-user@ws.apache.org
Subject: Axis 1.4 configuration to use HTTP/1.1
Hi All,
Please let me know if there is any way to configure Axis1.4 such that it
uses HTTP/1.1 instead of HTTP/1.0
The request from the soapclient (implemented using service stub) lands
with
Axis/1.4 which in turn by default presumably uses HTTP/1.0.
Can't this be changed somehow using CommonsHTTPSender as pointed by mail
thread of Mario/Jeff Axis 1.4 CommonsHTTPSender question Date
Sep:20:2007
?
Mario/Jeff,
Please let me know if you people have reached some solution and will
that
solution be helpful
Re: How to set HTTP/1.1 with Axis1.4
Thanks Alick! It is exactly what I need. Joan On 7/12/07, Alick Buckley [EMAIL PROTECTED] wrote: Hi, By default Apache Axis 1.4 uses ' org.apache.axis.transport.http.HTTPSender' for http sending. It is possible to change this to use 'org.apache.commons.httpclient'. Change the transport pivot attribute in the configuration to point to the CommonsHTTPSender class. transport name=http pivot=java: org.apache.axis.transport.http.CommonsHTTPSender/ The following is an example of an axis client configuration file. ?xml version=1.0 encoding=UTF-8? deployment name=defaultClientConfig xmlns=http://xml.apache.org/axis/wsdd/; xmlns:java=http://xml.apache.org/axis/wsdd/providers/java; globalConfiguration parameter name=disablePrettyXML value=true/ parameter name=enableNamespacePrefixOptimization value=false/ /globalConfiguration transport name=http pivot=java: org.apache.axis.transport.http.CommonsHTTPSender/ transport name=local pivot=java: org.apache.axis.transport.local.LocalSender/ transport name=java pivot=java: org.apache.axis.transport.java.JavaSender/ /deployment You also need to add the common.codec.1.3.jar and common-httpclient-3.0-rc4.jar to the jar directory. http://jakarta.apache.org/commons/ http://jakarta.apache.org/commons/httpclient/ http://jakarta.apache.org/commons/httpclient/features.html http://jakarta.apache.org/site/downloads/downloads_commons.html http://jakarta.apache.org/commons/httpclient/logging.html By default commons http client uses HTTP protocol 1.1 and by default it uses chunked transfer encoding. So you might need to disable chunked transfer encoding = -Original Message- *From:* Joan Barrull [mailto:[EMAIL PROTECTED] *Sent:* Thursday, 12 July 2007 1:29 AM *To:* axis-user@ws.apache.org *Subject:* How to set HTTP/1.1 with Axis1.4 Hi guys, I am using Axis 1.4. My client, generated through wsdl2java, works fine. Following is the piece of code that sends the request: MyServiceLocator se = new MIBServiceLocator(); MyPortType stub = se.getMIBPort(new java.net.URL(endPointMIB)); Problem is, when I monitor the request through the tcpmonitor, I get the following header: POST /isadpt_grupo1 HTTP/1.0 How can I modify my code in order to send through HTTP/1.1 instead of HTTP/1.0? Thanks in advance, joan
How to set HTTP/1.1 with Axis1.4
Hi guys, I am using Axis 1.4. My client, generated through wsdl2java, works fine. Following is the piece of code that sends the request: MyServiceLocator se = new MIBServiceLocator(); MyPortType stub = se.getMIBPort(new java.net.URL(endPointMIB)); Problem is, when I monitor the request through the tcpmonitor, I get the following header: POST /isadpt_grupo1 HTTP/1.0 How can I modify my code in order to send through HTTP/1.1 instead of HTTP/1.0? Thanks in advance, joan
RE: How to set HTTP/1.1 with Axis1.4
Hi, By default Apache Axis 1.4 uses 'org.apache.axis.transport.http.HTTPSender' for http sending. It is possible to change this to use 'org.apache.commons.httpclient'. Change the transport pivot attribute in the configuration to point to the CommonsHTTPSender class. transport name=http pivot=java:org.apache.axis.transport.http.CommonsHTTPSender/ The following is an example of an axis client configuration file. ?xml version=1.0 encoding=UTF-8? deployment name=defaultClientConfig xmlns= http://xml.apache.org/axis/wsdd/ http://xml.apache.org/axis/wsdd/; xmlns:java= http://xml.apache.org/axis/wsdd/providers/java http://xml.apache.org/axis/wsdd/providers/java; globalConfiguration parameter name=disablePrettyXML value=true/ parameter name=enableNamespacePrefixOptimization value=false/ /globalConfiguration transport name=http pivot=java:org.apache.axis.transport.http.CommonsHTTPSender/ transport name=local pivot=java:org.apache.axis.transport.local.LocalSender/ transport name=java pivot=java:org.apache.axis.transport.java.JavaSender/ /deployment You also need to add the common.codec.1.3.jar and common-httpclient-3.0-rc4.jar to the jar directory. http://jakarta.apache.org/commons/ http://jakarta.apache.org/commons/ http://jakarta.apache.org/commons/httpclient/ http://jakarta.apache.org/commons/httpclient/ http://jakarta.apache.org/commons/httpclient/features.html http://jakarta.apache.org/commons/httpclient/features.html http://jakarta.apache.org/site/downloads/downloads_commons.html http://jakarta.apache.org/site/downloads/downloads_commons.html http://jakarta.apache.org/commons/httpclient/logging.html http://jakarta.apache.org/commons/httpclient/logging.html By default commons http client uses HTTP protocol 1.1 and by default it uses chunked transfer encoding. So you might need to disable chunked transfer encoding = -Original Message- From: Joan Barrull [mailto:[EMAIL PROTECTED] Sent: Thursday, 12 July 2007 1:29 AM To: axis-user@ws.apache.org Subject: How to set HTTP/1.1 with Axis1.4 Hi guys, I am using Axis 1.4. My client, generated through wsdl2java, works fine. Following is the piece of code that sends the request: MyServiceLocator se = new MIBServiceLocator(); MyPortType stub = se.getMIBPort(new java.net.URL(endPointMIB)); Problem is, when I monitor the request through the tcpmonitor, I get the following header: POST /isadpt_grupo1 HTTP/1.0 How can I modify my code in order to send through HTTP/1.1 instead of HTTP/1.0? Thanks in advance, joan
HTTP/1.1 400 Bad Request
Hi again, I was trying to get some information on this problem but I couldn't know what is happening so I'm trying again. Does anybody know anything about how can I fix this??? Thanks a lot, Jorge Fernández Jorge Fernandez [EMAIL PROTECTED] escribió: Hi all, I'm having problems only when throwing exceptions. I'm getting bad request. This problem appeared since I moved to axis2 1.2, using it with Tomcat. If I use axis as standalone server there's no problem. The messages are apparently the same except for some minimal changes in the order of HTTP header, the prefix for the description element namespace and that the final character after envelope in one case appears in the following line. This are the messages: The correct one with standalone axis: HTTP/1.1 500 Internal server error Date: Wed, 13 Jun 2007 08:22:37 GMT Content-Type: application/soap+xml; action=http://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault; Server: Simple-Server/1.1 Transfer-Encoding: chunked Connection: Close 3a2 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:wsa=http://www.w3.org/2005/08/addressing; xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header wsa:Actionhttp://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault/wsa:Action wsa:RelatesTourn:uuid:B2AFE74A4124DE7BFF1181722957402/wsa:RelatesTo /soapenv:Header soapenv:Body soapenv:Fault soapenv:Code soapenv:Valuesoapenv:Sender/soapenv:Value /soapenv:Code soapenv:Reason soapenv:Text xml:lang=en-USValidationFaultException/soapenv:Text /soapenv:Reason soapenv:Detail ns4:ValidationException xmlns:ns4=http://op_messages.medici_link/xsd; ns4:ValidationFault s2:description xmlns:s2=http://faults.medici_link/xsd;User not validated. You must validate before invoking a method./s2:description /ns4:ValidationFault /ns4:ValidationException /soapenv:Detail /soapenv:Fault /soapenv:Body /soapenv:Envelope0 The bad one with tomcat: HTTP/1.1 400 Petición incorrecta Server: Apache-Coyote/1.1 Content-Type: application/soap+xml; action=http://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault;charset=UTF-8 Transfer-Encoding: chunked Date: Wed, 13 Jun 2007 08:12:50 GMT Connection: close 3a2 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:wsa=http://www.w3.org/2005/08/addressing; xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header wsa:Actionhttp://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault/wsa:Action wsa:RelatesTourn:uuid:61931C3AAB6FF83F181181722371001/wsa:RelatesTo /soapenv:Header soapenv:Body soapenv:Fault soapenv:Code soapenv:Valuesoapenv:Sender/soapenv:Value /soapenv:Code soapenv:Reason soapenv:Text xml:lang=en-USValidationFaultException/soapenv:Text /soapenv:Reason soapenv:Detail ns4:ValidationException xmlns:ns4=http://op_messages.medici_link/xsd; ns4:ValidationFault s1:description xmlns:s1=http://faults.medici_link/xsd;User not validated. You must validate before invoking a method./s1:description /ns4:ValidationFault /ns4:ValidationException /soapenv:Detail /soapenv:Fault /soapenv:Body /soapenv:Envelope 0 - LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com - ¡Descubre una nueva forma de obtener respuestas a tus preguntas! Entra en Yahoo! Respuestas.
Re: HTTP/1.1 400 Bad Request
undecipherable characters (specifically 3a2) is being introduced before the beginning xml tag which neither the servlet or the client stub can interpret I have seen this happen with Chunked encoding try to disable parameter name=Transfer-Encoding (commenting out the parameter name=Transfer-Encoding from axis2.xml) and re-deploy Saludos M-- This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: Jorge Fernandez To: axis-user@ws.apache.org Sent: Thursday, June 21, 2007 3:40 PM Subject: HTTP/1.1 400 Bad Request Hi again, I was trying to get some information on this problem but I couldn't know what is happening so I'm trying again. Does anybody know anything about how can I fix this??? Thanks a lot, Jorge Fernández Jorge Fernandez [EMAIL PROTECTED] escribió: Hi all, I'm having problems only when throwing exceptions. I'm getting bad request. This problem appeared since I moved to axis2 1.2, using it with Tomcat. If I use axis as standalone server there's no problem. The messages are apparently the same except for some minimal changes in the order of HTTP header, the prefix for the description element namespace and that the final character after envelope in one case appears in the following line. This are the messages: The correct one with standalone axis: HTTP/1.1 500 Internal server error Date: Wed, 13 Jun 2007 08:22:37 GMT Content-Type: application/soap+xml; action=http://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault; Server: Simple-Server/1.1 Transfer-Encoding: chunked Connection: Close 3a2 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:wsa=http://www.w3.org/2005/08/addressing; xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header wsa:Actionhttp://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault/wsa:Action wsa:RelatesTourn:uuid:B2AFE74A4124DE7BFF1181722957402/wsa:RelatesTo /soapenv:Header soapenv:Body soapenv:Fault soapenv:Code soapenv:Valuesoapenv:Sender/soapenv:Value /soapenv:Code soapenv:Reason soapenv:Text xml:lang=en-USValidationFaultException/soapenv:Text /soapenv:Reason soapenv:Detail ns4:ValidationException xmlns:ns4=http://op_messages.medici_link/xsd; ns4:ValidationFault s2:description xmlns:s2=http://faults.medici_link/xsd;User not validated. You must validate before invoking a method./s2:description /ns4:ValidationFault /ns4:ValidationException /soapenv:Detail /soapenv:Fault /soapenv:Body /soapenv:Envelope0 The bad one with tomcat: HTTP/1.1 400 Petición incorrecta Server: Apache-Coyote/1.1 Content-Type: application/soap+xml; action=http://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault;charset=UTF-8 Transfer-Encoding: chunked Date: Wed, 13 Jun 2007 08:12:50 GMT Connection: close 3a2 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:wsa=http://www.w3.org/2005/08/addressing; xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header wsa:Actionhttp://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault/wsa:Action wsa:RelatesTourn:uuid:61931C3AAB6FF83F181181722371001/wsa:RelatesTo /soapenv:Header soapenv:Body soapenv:Fault soapenv:Code soapenv:Valuesoapenv:Sender/soapenv:Value /soapenv:Code soapenv:Reason soapenv:Text xml:lang=en-USValidationFaultException/soapenv:Text /soapenv:Reason soapenv:Detail ns4:ValidationException xmlns:ns4=http://op_messages.medici_link/xsd; ns4:ValidationFault s1:description xmlns:s1=http://faults.medici_link/xsd;User not validated. You must validate before invoking a method./s1:description /ns4:ValidationFault /ns4:ValidationException /soapenv:Detail /soapenv:Fault /soapenv:Body /soapenv:Envelope 0 LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http
Re: HTTP/1.1 400 Bad Request
Hola Martin: I tried what you said but the problem is the same. Furthermore, those characters remain appearing even commenting every Transfer-Encoding parameter. I think that it's something related to Tomcat because the code 400 on HTTP header only appears when deploying Axis2 under Tomcat. Saludos y muchas gracias again, Jorge Fernandez Martin Gainty [EMAIL PROTECTED] escribió: undecipherable characters (specifically 3a2) is being introduced before the beginning xml tag which neither the servlet or the client stub can interpret I have seen this happen with Chunked encoding try to disable parameter name=Transfer-Encoding (commenting out the parameter name=Transfer-Encoding from axis2.xml) and re-deploy Saludos M-- This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From:Jorge Fernandez To: axis-user@ws.apache.org Sent: Thursday, June 21, 2007 3:40PM Subject: HTTP/1.1 400 Bad Request Hi again, I was trying to get some information on thisproblem but I couldn't know what is happening so I'm trying again. Doesanybody know anything about how can I fix this??? Thanks alot, Jorge Fernández Jorge Fernandez [EMAIL PROTECTED]escribió: Hi all, I'm having problems only when throwing exceptions. I'm getting bad request. This problem appeared since I moved to axis2 1.2, using it with Tomcat. If I use axis as standalone server there's no problem. The messages are apparently the same except for some minimal changes in the order of HTTP header, the prefix for the description element namespace and that the final character after envelope in one case appears in the following line. This are the messages: The correct one with standalone axis: HTTP/1.1 500 Internal server error Date: Wed, 13 Jun 2007 08:22:37 GMT Content-Type: application/soap+xml; action=http://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault; Server: Simple-Server/1.1 Transfer-Encoding: chunked Connection: Close 3a2 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:wsa=http://www.w3.org/2005/08/addressing; xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header wsa:Actionhttp://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault/wsa:Action wsa:RelatesTourn:uuid:B2AFE74A4124DE7BFF1181722957402/wsa:RelatesTo /soapenv:Header soapenv:Body soapenv:Fault soapenv:Code soapenv:Valuesoapenv:Sender/soapenv:Value /soapenv:Code soapenv:Reason soapenv:Text xml:lang=en-USValidationFaultException/soapenv:Text /soapenv:Reason soapenv:Detail ns4:ValidationException xmlns:ns4=http://op_messages.medici_link/xsd; ns4:ValidationFault s2:description xmlns:s2=http://faults.medici_link/xsd;User not validated. You must validate before invoking a method./s2:description /ns4:ValidationFault /ns4:ValidationException /soapenv:Detail /soapenv:Fault /soapenv:Body /soapenv:Envelope0 The bad one with tomcat: HTTP/1.1 400 Petición incorrecta Server: Apache-Coyote/1.1 Content-Type: application/soap+xml; action=http://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault;charset=UTF-8 Transfer-Encoding: chunked Date: Wed, 13 Jun 2007 08:12:50 GMT Connection: close 3a2 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:wsa=http://www.w3.org/2005/08/addressing; xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header wsa:Actionhttp://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault/wsa:Action wsa:RelatesTourn:uuid:61931C3AAB6FF83F181181722371001/wsa:RelatesTo /soapenv:Header soapenv:Body soapenv:Fault soapenv:Code soapenv:Valuesoapenv:Sender/soapenv:Value /soapenv:Code soapenv:Reason soapenv:Text xml:lang=en-USValidationFaultException/soapenv:Text /soapenv:Reason soapenv:Detail ns4:ValidationException xmlns:ns4=http://op_messages.medici_link/xsd; ns4:ValidationFault s1:description xmlns:s1
Re: HTTP/1.1 400 Bad Request
Buenas Dias Jorge Please post your WSDL Saludos desde EEUU! M-- This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: Jorge Fernandez To: axis-user@ws.apache.org ; Martin Gainty Sent: Thursday, June 21, 2007 4:41 PM Subject: Re: HTTP/1.1 400 Bad Request Hola Martin: I tried what you said but the problem is the same. Furthermore, those characters remain appearing even commenting every Transfer-Encoding parameter. I think that it's something related to Tomcat because the code 400 on HTTP header only appears when deploying Axis2 under Tomcat. Saludos y muchas gracias again, Jorge Fernandez Martin Gainty [EMAIL PROTECTED] escribió: undecipherable characters (specifically 3a2) is being introduced before the beginning xml tag which neither the servlet or the client stub can interpret I have seen this happen with Chunked encoding try to disable parameter name=Transfer-Encoding (commenting out the parameter name=Transfer-Encoding from axis2.xml) and re-deploy Saludos M-- This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: Jorge Fernandez To: axis-user@ws.apache.org Sent: Thursday, June 21, 2007 3:40 PM Subject: HTTP/1.1 400 Bad Request Hi again, I was trying to get some information on this problem but I couldn't know what is happening so I'm trying again. Does anybody know anything about how can I fix this??? Thanks a lot, Jorge Fernández Jorge Fernandez [EMAIL PROTECTED] escribió: Hi all, I'm having problems only when throwing exceptions. I'm getting bad request. This problem appeared since I moved to axis2 1.2, using it with Tomcat. If I use axis as standalone server there's no problem. The messages are apparently the same except for some minimal changes in the order of HTTP header, the prefix for the description element namespace and that the final character after envelope in one case appears in the following line. This are the messages: The correct one with standalone axis: HTTP/1.1 500 Internal server error Date: Wed, 13 Jun 2007 08:22:37 GMT Content-Type: application/soap+xml; action=http://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault; Server: Simple-Server/1.1 Transfer-Encoding: chunked Connection: Close 3a2 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:wsa=http://www.w3.org/2005/08/addressing; xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header wsa:Actionhttp://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault/wsa:Action wsa:RelatesTourn:uuid:B2AFE74A4124DE7BFF1181722957402/wsa:RelatesTo /soapenv:Header soapenv:Body soapenv:Fault soapenv:Code soapenv:Valuesoapenv:Sender/soapenv:Value /soapenv:Code soapenv:Reason soapenv:Text xml:lang=en-USValidationFaultException/soapenv:Text /soapenv:Reason soapenv:Detail ns4:ValidationException xmlns:ns4=http://op_messages.medici_link/xsd; ns4:ValidationFault s2:description xmlns:s2=http://faults.medici_link/xsd;User not validated. You must validate before invoking a method./s2:description /ns4:ValidationFault /ns4:ValidationException /soapenv:Detail /soapenv:Fault /soapenv:Body /soapenv:Envelope0 The bad one with tomcat: HTTP/1.1 400 Petición incorrecta Server: Apache-Coyote/1.1 Content-Type: application/soap+xml; action=http://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault;charset=UTF-8 Transfer-Encoding: chunked Date: Wed, 13 Jun 2007 08:12:50 GMT Connection: close 3a2 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:wsa=http://www.w3.org/2005/08/addressing; xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header
HTTP/1.1 400 Petición incorrecta
Hi all, I'm having problems only when throwing exceptions. I'm getting bad request. This problem appeared since I moved to axis2 1.2, using it with Tomcat. If I use axis as standalone server there's no problem. The messages are apparently the same except for some minimal changes in the order of HTTP header, the prefix for the description element namespace and that the final character after envelope in one case appears in the following line. This are the messages: The correct one with standalone axis: HTTP/1.1 500 Internal server error Date: Wed, 13 Jun 2007 08:22:37 GMT Content-Type: application/soap+xml; action=http://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault; Server: Simple-Server/1.1 Transfer-Encoding: chunked Connection: Close 3a2 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:wsa=http://www.w3.org/2005/08/addressing; xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header wsa:Actionhttp://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault/wsa:Action wsa:RelatesTourn:uuid:B2AFE74A4124DE7BFF1181722957402/wsa:RelatesTo /soapenv:Header soapenv:Body soapenv:Fault soapenv:Code soapenv:Valuesoapenv:Sender/soapenv:Value /soapenv:Code soapenv:Reason soapenv:Text xml:lang=en-USValidationFaultException/soapenv:Text /soapenv:Reason soapenv:Detail ns4:ValidationException xmlns:ns4=http://op_messages.medici_link/xsd; ns4:ValidationFault s2:description xmlns:s2=http://faults.medici_link/xsd;User not validated. You must validate before invoking a method./s2:description /ns4:ValidationFault /ns4:ValidationException /soapenv:Detail /soapenv:Fault /soapenv:Body /soapenv:Envelope0 The bad one with tomcat: HTTP/1.1 400 Petición incorrecta Server: Apache-Coyote/1.1 Content-Type: application/soap+xml; action=http://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault;charset=UTF-8 Transfer-Encoding: chunked Date: Wed, 13 Jun 2007 08:12:50 GMT Connection: close 3a2 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:wsa=http://www.w3.org/2005/08/addressing; xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header wsa:Actionhttp://medici_link/Medici_LinkPortType/validateUser/Fault/ValidationFault/wsa:Action wsa:RelatesTourn:uuid:61931C3AAB6FF83F181181722371001/wsa:RelatesTo /soapenv:Header soapenv:Body soapenv:Fault soapenv:Code soapenv:Valuesoapenv:Sender/soapenv:Value /soapenv:Code soapenv:Reason soapenv:Text xml:lang=en-USValidationFaultException/soapenv:Text /soapenv:Reason soapenv:Detail ns4:ValidationException xmlns:ns4=http://op_messages.medici_link/xsd; ns4:ValidationFault s1:description xmlns:s1=http://faults.medici_link/xsd;User not validated. You must validate before invoking a method./s1:description /ns4:ValidationFault /ns4:ValidationException /soapenv:Detail /soapenv:Fault /soapenv:Body /soapenv:Envelope 0 - LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com
AW: HTTP/1.1 400 Bad Request
Hi Martin, thanks a lot for your reply. The error I am getting was expected :-) I requested a non existing document from the Content Manager, thats what the exception is about. What I am trying to achive is that the client is notified of the error. Since my server code throws exceptions this is the preferred way. But whenever an exception is thrown AXIS2 returns a HTTP 400. In order for the exception to be correctly processed in the axis2 client it should be a HTTP 500 as shown by the faulthandler example. Any other ideas what might be wrong? P.S.: I am using Helper classes (wsdl2java -Eh option) Falko-Germar Schwarz (IBM) HIS16ES im Auftrage der HVB Information Services GmbH Am Tucherpark 12 D-80538 München phone +49 89 378-22001 mobil +49 0170 79 37 26 1 postal address Am Tucherpark 12, D-80538 München mailto:[EMAIL PROTECTED] http://www.hvbis.com/ mailto:[EMAIL PROTECTED] http://www.ibm.com/ HVB Information Services GmbH Member of UniCredit Group, Am Tucherpark 12, 80538 München Management: Gabriele Ruf, Klaus Rausch Chairman Supervisory Board: Matthias Sohler Legal form: GmbH, Registered Office: Munich, Register Court: Local Court Munich HR B 93804, Tax Number 143/102/30511 Important Note: This e-mail is only intended for the person or company/organisation named as recipient. It may contain trade secrets or undisclosed and confidential information or information otherwise protected by work-product immunity or other legal regulations. If you have received this email by mistake, we kindly ask you not to copy this message or use it for any purpose nor disclose its contents to any other person. Please inform us immediately and delete the original document. In addition, please let us know if you or your company object to receiving e-mails for messages of this kind. -Ursprüngliche Nachricht- Von: Martin Gainty [mailto:[EMAIL PROTECTED] Gesendet: Montag, 11. Juni 2007 17:42 An: axis-user@ws.apache.org Betreff: Re: HTTP/1.1 400 Bad Request I would verify your AxisService is operational (go to Axis Admin and verify the service is displayed) verify the operation name is correct verify the parameters for the Service are correct But this specific error has is a genuine IBM bug .It looks as if you will need DB2 Content Manager Version 8.3+ to work with 8.3 Library Server http://publib.boulder.ibm.com/infocenter/cmgmt/v8r3m0/index.jsp?topic=/com.ibm.sysadmin.hlp/trs00085.htm Viel Gluck, Martin-- This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: [EMAIL PROTECTED] To: axis-user@ws.apache.org Sent: Monday, June 11, 2007 11:19 AM Subject: HTTP/1.1 400 Bad Request Hi, when an exception occurs on server side I receive the Fault-Response with HTTP Code 400 instead of 500. Axis 2 then simply returns Bad Request but not the original server exception. Any ideas why I get the 400? Here is the response message: HEADER: -- HTTP/1.1 400 Bad Request Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_90725D1D34C74FB4681181575011626; type=application/xop+xml; start=0.urn:uuid:[EMAIL PROTECTED]; start-info=application/soap+xml; charset=UTF-8; action=http://soap.server.aat.hvb.de/Archive2007PortType/getDocument/Fault/getDocumentFault; Content-Language: de-DE Transfer-Encoding: chunked Date: Mon, 11 Jun 2007 15:16:51 GMT Server: WebSphere Application Server/6.0 -- Message: -- ?xml version=1.0 encoding=UTF-8?soapenv:Envelope xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope;soapenv:Bodysoapenv:Faultsoapenv:Codesoapenv:Valuesoapenv:Sender/soapenv:Value/soapenv:Codesoapenv:Reasonsoapenv:Text xml:lang=en-USFehler in GetDocument gefangen/soapenv:Text/soapenv:Reasonsoapenv:Detailns2:getDocumentFault xmlns:ns2=http://soap.server.aat.hvb.de/xsd;ns2:getDocumentFaultaxis2ns11:Server.Archive.00805.exception.service.unknown xmlns:axis2ns11=http
HTTP/1.1 400 Bad Request
Hi, when an exception occurs on server side I receive the Fault-Response with HTTP Code 400 instead of 500. Axis 2 then simply returns Bad Request but not the original server exception. Any ideas why I get the 400? Here is the response message: HEADER: -- HTTP/1.1 400 Bad Request Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_90725D1D34C74FB4681181575011626; type=application/xop+xml; start=0.urn:uuid:[EMAIL PROTECTED]; start-info=application/soap+xml; charset=UTF-8; action=http://soap.server.aat.hvb.de/Archive2007PortType/getDocument/Fault/getDocumentFault; Content-Language: de-DE Transfer-Encoding: chunked Date: Mon, 11 Jun 2007 15:16:51 GMT Server: WebSphere Application Server/6.0 -- Message: -- ?xml version=1.0 encoding=UTF-8?soapenv:Envelope xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope;soapenv:Bodysoapenv:Faultsoapenv:Codesoapenv:Valuesoapenv:Sender/soapenv:Value/soapenv:Codesoapenv:Reasonsoapenv:Text xml:lang=en-USFehler in GetDocument gefangen/soapenv:Text/soapenv:Reasonsoapenv:Detailns2:getDocumentFault xmlns:ns2=http://soap.server.aat.hvb.de/xsd;ns2:getDocumentFaultaxis2ns11:Server.Archive.00805.exception.service.unknown xmlns:axis2ns11=http://de.hvb.aat.service;Beim Aufruf der Service Methode getDocument_getDocument_AC_m000321 ist ein Fehler aufgetreten. Ursache: com.ibm.mm.sdk.common.DKUsageError: DGL3974A: Ungültige PID für DB2 Content Manager. DGL0303A: Ungültiger Parameter.[1234567890]/axis2ns11:Server.Archive.00805.exception.service.unknown -- Falko-Germar Schwarz (IBM) HIS16ES im Auftrage der HVB Information Services GmbH Am Tucherpark 12 D-80538 München phone +49 89 378-22001 mobil +49 0170 79 37 26 1 postal address Am Tucherpark 12, D-80538 München mailto:[EMAIL PROTECTED] http://www.hvbis.com/ mailto:[EMAIL PROTECTED] http://www.ibm.com/ HVB Information Services GmbH Member of UniCredit Group, Am Tucherpark 12, 80538 München Vorsitzender des Aufsichtsrats: Alessandro Profumo Vorstandsmitglieder: Willibald Cernko, Stefan Ermisch, Rolf Friedhofen, Heinz Laber, Dr. Stefan Schmittmann, Ronald Seilheimer, Matthias Sohler, Dr. Wolfgang Sprißler, Andrea Umberto Varese, Andreas Wölfer Bayerische Hypo- und Vereinsbank AG, Rechtsform: Aktiengesellschaft, Sitz: München, Registergericht: München HR B 42148, Steuer-Nr.: 143/102/30007, USt-IdNr.: DE 129273380 Important Note: This e-mail is only intended for the person or company/organisation named as recipient. It may contain trade secrets or undisclosed and confidential information or information otherwise protected by work-product immunity or other legal regulations. If you have received this email by mistake, we kindly ask you not to copy this message or use it for any purpose nor disclose its contents to any other person. Please inform us immediately and delete the original document. In addition, please let us know if you or your company object to receiving e-mails for messages of this kind.
Re: HTTP/1.1 400 Bad Request
HTTP/1.1 400 Bad RequestI would verify your AxisService is operational (go to Axis Admin and verify the service is displayed) verify the operation name is correct verify the parameters for the Service are correct But this specific error has is a genuine IBM bug ..It looks as if you will need DB2 Content Manager Version 8.3+ to work with 8.3 Library Server http://publib.boulder.ibm.com/infocenter/cmgmt/v8r3m0/index.jsp?topic=/com.ibm.sysadmin.hlp/trs00085.htm Viel Gluck, Martin-- This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: [EMAIL PROTECTED] To: axis-user@ws.apache.org Sent: Monday, June 11, 2007 11:19 AM Subject: HTTP/1.1 400 Bad Request Hi, when an exception occurs on server side I receive the Fault-Response with HTTP Code 400 instead of 500. Axis 2 then simply returns Bad Request but not the original server exception. Any ideas why I get the 400? Here is the response message: HEADER: -- HTTP/1.1 400 Bad Request Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_90725D1D34C74FB4681181575011626; type=application/xop+xml; start=0.urn:uuid:[EMAIL PROTECTED]; start-info=application/soap+xml; charset=UTF-8; action=http://soap.server.aat.hvb.de/Archive2007PortType/getDocument/Fault/getDocumentFault; Content-Language: de-DE Transfer-Encoding: chunked Date: Mon, 11 Jun 2007 15:16:51 GMT Server: WebSphere Application Server/6.0 -- Message: -- ?xml version=1.0 encoding=UTF-8?soapenv:Envelope xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope;soapenv:Bodysoapenv:Faultsoapenv:Codesoapenv:Valuesoapenv:Sender/soapenv:Value/soapenv:Codesoapenv:Reasonsoapenv:Text xml:lang=en-USFehler in GetDocument gefangen/soapenv:Text/soapenv:Reasonsoapenv:Detailns2:getDocumentFault xmlns:ns2=http://soap.server.aat.hvb.de/xsd;ns2:getDocumentFaultaxis2ns11:Server.Archive.00805.exception.service.unknown xmlns:axis2ns11=http://de.hvb.aat.service;Beim Aufruf der Service Methode getDocument_getDocument_AC_m000321 ist ein Fehler aufgetreten. Ursache: com.ibm.mm.sdk.common.DKUsageError: DGL3974A: Ungültige PID für DB2 Content Manager. DGL0303A: Ungültiger Parameter.[1234567890]/axis2ns11:Server.Archive.00805.exception.service.unknown -- Falko-Germar Schwarz (IBM) HIS16ES im Auftrage der HVB Information Services GmbH Am Tucherpark 12 D-80538 München phone +49 89 378-22001 mobil +49 0170 79 37 26 1 postal address Am Tucherpark 12, D-80538 München mailto:[EMAIL PROTECTED] http://www.hvbis.com/ mailto:[EMAIL PROTECTED] http://www.ibm.com/ HVB Information Services GmbH Member of UniCredit Group, Am Tucherpark 12, 80538 München Vorsitzender des Aufsichtsrats: Alessandro Profumo Vorstandsmitglieder: Willibald Cernko, Stefan Ermisch, Rolf Friedhofen, Heinz Laber, Dr. Stefan Schmittmann, Ronald Seilheimer, Matthias Sohler, Dr. Wolfgang Sprißler, Andrea Umberto Varese, Andreas Wölfer Bayerische Hypo- und Vereinsbank AG, Rechtsform: Aktiengesellschaft, Sitz: München, Registergericht: München HR B 42148, Steuer-Nr.: 143/102/30007, USt-IdNr.: DE 129273380 Important Note: This e-mail is only intended for the person or company/organisation named as recipient. It may contain trade secrets or undisclosed and confidential information or information otherwise protected by work-product immunity or other legal regulations. If you have received this email by mistake, we kindly ask you not to copy this message or use it for any purpose nor disclose its contents to any other person. Please inform us immediately and delete the original document. In addition, please let us know if you or your company object to receiving e-mails for messages of this kind.
[Axis2] HTTP/1.1 100
Hi, With my generic Axis client code, I am trying to invoke some services available on strikeIron web site. Interestingly, I can sucessfully invoke most of them but for some of them I get this error: INFO: Discarding unexpected response: HTTP/1.1 100 Continue org.apache.axis2.AxisFault: HTTP Transport error : '404' - 'File not found'; nested exception is: org.apache.axis2.AxisFault: HTTP Transport error : '404' - 'File not found'; nested exception is: org.apache.axis2.AxisFault: HTTP Transport error : '404' - 'File not found'; nested exception is: org.apache.axis2.AxisFault: HTTP Transport error : '404' - 'File not found' at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke( CommonsHTTPTransportSender.java:227) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:643) The services are actually there, you can try them out from the strikeIron interface. What does this error mean? Thanks, -Nirmit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] HTTP/1.1 100
Can you please log a JIRA bug with the specific service in question? and the client code/snippet to recreate the problem? thanks, dims On 10/16/06, Nirmit Desai [EMAIL PROTECTED] wrote: Hi, With my generic Axis client code, I am trying to invoke some services available on strikeIron web site. Interestingly, I can sucessfully invoke most of them but for some of them I get this error: INFO: Discarding unexpected response: HTTP/1.1 100 Continue org.apache.axis2.AxisFault: HTTP Transport error : '404' - 'File not found'; nested exception is: org.apache.axis2.AxisFault: HTTP Transport error : '404' - 'File not found'; nested exception is: org.apache.axis2.AxisFault: HTTP Transport error : '404' - 'File not found'; nested exception is: org.apache.axis2.AxisFault: HTTP Transport error : '404' - 'File not found' at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke( CommonsHTTPTransportSender.java:227) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:643) The services are actually there, you can try them out from the strikeIron interface. What does this error mean? Thanks, -Nirmit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Axis 1.4 Discarding unexpected response: HTTP/1.1 100 Continue?
Hi, I've searched the archives (and google) for 2 full days and still have not found the solution to this problem. I am using JRE/JDK 1.5.0, and Axis 1.4 with SOAP client generated from WSDL2Java. I have commonsHTTPSender enabled as the http transport by placing the correct client-config.wsdd in the app working directory. The .NET third party service I am trying to use (via SSL) requires two calls to be made together during a single connection. My understanding is that Commons-httpclient will do this. I have compiled Axis 1.4 from source with all libraries included. Everything compiled and runs fine. However, it appears that CommonsHTTPSender is opening a new connection for each call which is preventing the operation from succeeding. The first call is to send user credentials and the second call is for the action I wish to perform. I make the first call to log into the service, which returns success (logged in), and I get an error message from axis: Discarding unexpected response: HTTP/1.1 100 Continue Then I make my second call (the action call) and I receive a not logged in error from the service follow by Discarding unexpected response: HTTP/1.1 100 Continue I have tried using locator.setMaintainSession(true) with no effect. Please help, I've been trying to get past this for days and this is the only thing holding up my project. Is there something else I am missing? Am I troubleshooting the correct problem? Help! Thanks in advance, -tom
Re: Frustrating experience with Axis2 due to HTTP 1.1 and Chunked Transfer-Encoding
Ok, next step is get Axis2 nightly builds (http://people.apache.org/dist/axis2/nightly/axis2-std-SNAPSHOT-bin.zip) and check against them without disabling chunking. We've fixed lots of bugs since Axis2 1.0, so I think this must also be fixed by now, if there was a bug. -- Chinthaka Dapeng Wang wrote: Hi, Eran. thanks. It works now. It would be great, if you have a solution for me, so that it still works with chunking turned on. regards Dapeng Original-Nachricht Datum: Mon, 07 Aug 2006 02:35:54 +0530 Von: Eran Chinthaka [EMAIL PROTECTED] An: axis-user@ws.apache.org Betreff: Re: Frustrating experience with Axis2 due to HTTP 1.1 and Chunked Transfer-Encoding Dapeng Wang wrote: Hi, Eran, thank you for your hint. But there seems to be no constant called CHUNKED anymore in the class. Neither is there any constant called NTLM_AUTHENTICATION as documented on the wso2 website. HTTPConstants.HEADER_TRANSFER_ENCODING_CHUNKED is also not the right one. Oops sorry. Those constants are meant to be used with the latest nightly builds. Recently we refactored the constants to better places. Seems you are using Axis2 1.0 released version. If yes then use org.apache.axis2.context.MessageContextConstants.CHUNKED So I am just even more frustrated. Anyway, the engine should also run without problem with chunking turned on. Yep agreed. But I wanted to make sure first that it works and then address the problem. -- Chinthaka signature.asc Description: OpenPGP digital signature
Frustrating experience with Axis2 due to HTTP 1.1 and Chunked Transfer-Encoding
Hi,
I ran into a very frustrating problem and have no solution until now. After
downloaded and installed Axis 1.0, HappyAxis.jsp is just not happy. Version-WS
just can't be invoked. The same is true if I deploy my own service and run the
client.
After seeking and trying the whole weekend, I figured out that it has something
to do with the cunked transfer encoding. It seems that the Stax-Parser has got
the raw http stream to parse, so that it always ends in
com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
at [row,col {unknown-source}]: [1,0]
which is wrapped by an OMException, so that you can't see the real reason of
the failure at first sight.
TCPMON captures following request and response:
Request:
POST /axis2/services/version HTTP/1.1
User-Agent: Axis/2.0
SOAPAction:
Host: localhost:8081
Transfer-Encoding: chunked
Content-Type: text/xml; charset=UTF-8
10e
?xml version='1.0' encoding='UTF-8'?soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;soapenv:Header
/soapenv:Bodyns1:getVersion
xmlns:ns1=http://axisversion.sample/xsd;ns1:myValue
//ns1:getVersion/soapenv:Body/soapenv:Envelope
0
Response:
HTTP/1.1 500 Internal Server Error
Content-Type: text/html
Content-Language: de-DE
Content-Length: 1540
Date: Sun, 06 Aug 2006 16:24:41 GMT
Server: Apache-Coyote/1.1
Connection: close
htmlheadtitleApache Tomcat/5.0.25 - Error report/titlestyle!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;}
B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--/style
/headbodyh1HTTP Status 500 - /h1HR size=1
noshade=noshadepbtype/b Exception report/ppbmessage/b
u/u/ppbdescription/b uThe server encountered an internal error ()
that prevented it from fulfilling this request./u/ppbexception/b
prejava.lang.NullPointerException
org.apache.axis2.engine.AxisEngine.createFaultMessageContext(AxisEngine.java:183)
org.apache.axis2.transport.http.AxisServlet.handleFault(AxisServlet.java:168)
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:153)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
/pre/ppbnote/b uThe full stack trace of the root cause is available
in the Apache Tomcat/5.0.25 logs./u/pHR size=1
noshade=noshadeh3Apache Tomcat/5.0.25/h3/body/html
Tried different JDK and Tomcat combination: jdk1.4.2_10 with Tomcat 5.0.25 and
JDK1.5.7 with Tomcat 5.5.12. Always same result. Very frustrating.
The only way to have at least something to work to configure the
CommonsHttpSender to sue HTTP 1.0.
Can you please take a look into this. I really like to start with Axis2 without
these problems.
Best regards
Dapeng Wang
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit!
Feel free mit GMX DSL: http://www.gmx.net/de/go/dsl
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Frustrating experience with Axis2 due to HTTP 1.1 and Chunked Transfer-Encoding
Hi Dapeng,
Can u try disabling chunking?
(http://www.wso2.net/articles/axis2/java/2006/08/01/client-api-parameters#CHUNKED)C
- EC
Dapeng Wang wrote:
Hi,
I ran into a very frustrating problem and have no solution until now. After
downloaded and installed Axis 1.0, HappyAxis.jsp is just not happy.
Version-WS just can't be invoked. The same is true if I deploy my own service
and run the client.
After seeking and trying the whole weekend, I figured out that it has
something to do with the cunked transfer encoding. It seems that the
Stax-Parser has got the raw http stream to parse, so that it always ends in
com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
at [row,col {unknown-source}]: [1,0]
which is wrapped by an OMException, so that you can't see the real reason of
the failure at first sight.
TCPMON captures following request and response:
Request:
POST /axis2/services/version HTTP/1.1
User-Agent: Axis/2.0
SOAPAction:
Host: localhost:8081
Transfer-Encoding: chunked
Content-Type: text/xml; charset=UTF-8
10e
?xml version='1.0' encoding='UTF-8'?soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;soapenv:Header
/soapenv:Bodyns1:getVersion
xmlns:ns1=http://axisversion.sample/xsd;ns1:myValue
//ns1:getVersion/soapenv:Body/soapenv:Envelope
0
Response:
HTTP/1.1 500 Internal Server Error
Content-Type: text/html
Content-Language: de-DE
Content-Length: 1540
Date: Sun, 06 Aug 2006 16:24:41 GMT
Server: Apache-Coyote/1.1
Connection: close
htmlheadtitleApache Tomcat/5.0.25 - Error report/titlestyle!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--/style
/headbodyh1HTTP Status 500 - /h1HR size=1
noshade=noshadepbtype/b Exception report/ppbmessage/b
u/u/ppbdescription/b uThe server encountered an internal error
() that prevented it from fulfilling this request./u/ppbexception/b
prejava.lang.NullPointerException
org.apache.axis2.engine.AxisEngine.createFaultMessageContext(AxisEngine.java:183)
org.apache.axis2.transport.http.AxisServlet.handleFault(AxisServlet.java:168)
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:153)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
/pre/ppbnote/b uThe full stack trace of the root cause is
available in the Apache Tomcat/5.0.25 logs./u/pHR size=1
noshade=noshadeh3Apache Tomcat/5.0.25/h3/body/html
Tried different JDK and Tomcat combination: jdk1.4.2_10 with Tomcat 5.0.25
and JDK1.5.7 with Tomcat 5.5.12. Always same result. Very frustrating.
The only way to have at least something to work to configure the
CommonsHttpSender to sue HTTP 1.0.
Can you please take a look into this. I really like to start with Axis2
without these problems.
Best regards
Dapeng Wang
signature.asc
Description: OpenPGP digital signature
Re: Frustrating experience with Axis2 due to HTTP 1.1 and Chunked Transfer-Encoding
Hi, Eran,
thank you for your hint. But there seems to be no constant called CHUNKED
anymore in the class. Neither is there any constant called NTLM_AUTHENTICATION
as documented on the wso2 website.
HTTPConstants.HEADER_TRANSFER_ENCODING_CHUNKED is also not the right one.
So I am just even more frustrated. Anyway, the engine should also run without
problem with chunking turned on.
Any idea?
Best regards
Dapeng
Original-Nachricht
Datum: Mon, 07 Aug 2006 01:21:16 +0530
Von: Eran Chinthaka [EMAIL PROTECTED]
An: axis-user@ws.apache.org
Betreff: Re: Frustrating experience with Axis2 due to HTTP 1.1 and Chunked
Transfer-Encoding
Hi Dapeng,
Can u try disabling chunking?
(http://www.wso2.net/articles/axis2/java/2006/08/01/client-api-parameters#CHUNKED)C
- EC
Dapeng Wang wrote:
Hi,
I ran into a very frustrating problem and have no solution until now.
After downloaded and installed Axis 1.0, HappyAxis.jsp is just not happy.
Version-WS just can't be invoked. The same is true if I deploy my own service
and run the client.
After seeking and trying the whole weekend, I figured out that it has
something to do with the cunked transfer encoding. It seems that the
Stax-Parser has got the raw http stream to parse, so that it always ends in
com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
at [row,col {unknown-source}]: [1,0]
which is wrapped by an OMException, so that you can't see the real
reason of the failure at first sight.
TCPMON captures following request and response:
Request:
POST /axis2/services/version HTTP/1.1
User-Agent: Axis/2.0
SOAPAction:
Host: localhost:8081
Transfer-Encoding: chunked
Content-Type: text/xml; charset=UTF-8
10e
?xml version='1.0' encoding='UTF-8'?soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;soapenv:Header
/soapenv:Bodyns1:getVersion
xmlns:ns1=http://axisversion.sample/xsd;ns1:myValue
//ns1:getVersion/soapenv:Body/soapenv:Envelope
0
Response:
HTTP/1.1 500 Internal Server Error
Content-Type: text/html
Content-Language: de-DE
Content-Length: 1540
Date: Sun, 06 Aug 2006 16:24:41 GMT
Server: Apache-Coyote/1.1
Connection: close
htmlheadtitleApache Tomcat/5.0.25 - Error
report/titlestyle!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--/style
/headbodyh1HTTP Status 500 - /h1HR size=1
noshade=noshadepbtype/b Exception report/ppbmessage/b
u/u/ppbdescription/b uThe server encountered an internal error
() that prevented it from
fulfilling this request./u/ppbexception/b
prejava.lang.NullPointerException
org.apache.axis2.engine.AxisEngine.createFaultMessageContext(AxisEngine.java:183)
org.apache.axis2.transport.http.AxisServlet.handleFault(AxisServlet.java:168)
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:153)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
/pre/ppbnote/b uThe full stack trace of the root cause is
available in the Apache Tomcat/5.0.25 logs./u/pHR size=1
noshade=noshadeh3Apache Tomcat/5.0.25/h3/body/html
Tried different JDK and Tomcat combination: jdk1.4.2_10 with Tomcat
5.0.25 and JDK1.5.7 with Tomcat 5.5.12. Always same result. Very frustrating.
The only way to have at least something to work to configure the
CommonsHttpSender to sue HTTP 1.0.
Can you please take a look into this. I really like to start with Axis2
without these problems.
Best regards
Dapeng Wang
--
Feel free – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Frustrating experience with Axis2 due to HTTP 1.1 and Chunked Transfer-Encoding
Dapeng Wang wrote: Hi, Eran, thank you for your hint. But there seems to be no constant called CHUNKED anymore in the class. Neither is there any constant called NTLM_AUTHENTICATION as documented on the wso2 website. HTTPConstants.HEADER_TRANSFER_ENCODING_CHUNKED is also not the right one. Oops sorry. Those constants are meant to be used with the latest nightly builds. Recently we refactored the constants to better places. Seems you are using Axis2 1.0 released version. If yes then use org.apache.axis2.context.MessageContextConstants.CHUNKED So I am just even more frustrated. Anyway, the engine should also run without problem with chunking turned on. Yep agreed. But I wanted to make sure first that it works and then address the problem. -- Chinthaka signature.asc Description: OpenPGP digital signature
Re: Frustrating experience with Axis2 due to HTTP 1.1 and Chunked Transfer-Encoding
Hi, Eran. thanks. It works now. It would be great, if you have a solution for me, so that it still works with chunking turned on. regards Dapeng Original-Nachricht Datum: Mon, 07 Aug 2006 02:35:54 +0530 Von: Eran Chinthaka [EMAIL PROTECTED] An: axis-user@ws.apache.org Betreff: Re: Frustrating experience with Axis2 due to HTTP 1.1 and Chunked Transfer-Encoding Dapeng Wang wrote: Hi, Eran, thank you for your hint. But there seems to be no constant called CHUNKED anymore in the class. Neither is there any constant called NTLM_AUTHENTICATION as documented on the wso2 website. HTTPConstants.HEADER_TRANSFER_ENCODING_CHUNKED is also not the right one. Oops sorry. Those constants are meant to be used with the latest nightly builds. Recently we refactored the constants to better places. Seems you are using Axis2 1.0 released version. If yes then use org.apache.axis2.context.MessageContextConstants.CHUNKED So I am just even more frustrated. Anyway, the engine should also run without problem with chunking turned on. Yep agreed. But I wanted to make sure first that it works and then address the problem. -- Chinthaka -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! Feel free mit GMX DSL: http://www.gmx.net/de/go/dsl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HTTP 1.1
I am using Axis 1.2.1 for my Web Service client. I am issuing HTTP 1.0 requests and the server is sending me HTTP 1.1 responses. Can I configure my client to use HTTP 1.1 instead of 1.0? Thank you Fady
add Content-length on http/1.1 response
Hi all, i have interoparablity problems with one webservice client that need content-length on web services responses. As i read on RFCs, axis source code, and google searches, servlets container as tomcat use transfer-encoding chunked if axis don't call setContentLength on AxisServlet Response. My question is how can't i configure my web services to set content-length on the response. Regards, Enrique -- ___ Enrique Rodriguez Lasterra Asociación javaHispano lasterra AT javahispano DOT org
Configure Axis WS client to use HTTP/1.1
Hi I'am relatively new to Axis. I need to configure my axis Client to use HTTP/1.1 instead of HTTP/1.0. I've searched this List and the Web but cannot find any description on how to do this. Can anyone point me in the correct direction here ? Thanks Clement
using Axis client with HTTP/1.1 and pipeling
Hi, I heard that it requires some extra work to make Axis client work with HTTP/1.1. Let's assume it works with HTTP/1.1, how does it take advantage of HTTP/1.1 's pipelinig feature ? Given the fact that each client call is a synchronized call. My understanding is that even you could have multiple threads to call mulitple stub methods "simultaneously", those Soap requests would be sent over multiple *different* connections, instead of pipelined into a single connection. Any hint on this will be appreciated. Feng
RE: POST HTTP/1.1
Change your sender config to use commonsHTTPSender instead of the default HTTPSender class. Cheers Simon -Original Message- From: Ada Lam [mailto:[EMAIL PROTECTED] Sent: Friday, April 08, 2005 1:10 PM To: axis-user@ws.apache.org Subject: POST HTTP/1.1 Hi all, I am currently using axis 1.2 RC3. I want to send SOAP message to server via POST HTTP/1.1. However, axis is using POST HTTP/1.0. I've tried to change it by doing: call.getMessageContext().setProperty(org.apache.axis.MessageCo ntext.HTTP_TRANSPORT_VERSION, org.apache.axis.transport.http.HTTPConstants.HEADER_PROTOCOL_11); But it doesn't work. How can I change the HTTP version from 1.0 to 1.1 in axis? Thanks in advance! Regards, Ada
Re: POST HTTP/1.1
Thanks Simon. Do you happen to know if using the CommonsHTTPSender will solve the handling of multiple cookies also? http://issues.apache.org/jira/browse/AXIS-1080 Tim Simon Fell wrote: See this document for an example, it also supports digest auth http://www.devx.com/DevX/Article/21911/1763 -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Tim K. (Gmane) Sent: Friday, April 08, 2005 1:39 PM To: axis-user@ws.apache.org Subject: Re: POST HTTP/1.1 Simon, How do you reconfigure it to use CommonsHTTPSender? Do you have an example please? Also, would it be possible to use some other HTTPClient that would support digest auth, etc.? Thanks. Tim Simon Fell wrote: Change your sender config to use commonsHTTPSender instead of the default HTTPSender class. Cheers Simon -Original Message- From: Ada Lam [mailto:[EMAIL PROTECTED] Sent: Friday, April 08, 2005 1:10 PM To: axis-user@ws.apache.org Subject: POST HTTP/1.1 Hi all, I am currently using axis 1.2 RC3. I want to send SOAP message to server via POST HTTP/1.1. However, axis is using POST HTTP/1.0. I've tried to change it by doing: call.getMessageContext().setProperty(org.apache.axis.MessageCo ntext.HTTP_TRANSPORT_VERSION, org.apache.axis.transport.http.HTTPConstants.HEADER_PROTOCOL_11); But it doesn't work. How can I change the HTTP version from 1.0 to 1.1 in axis? Thanks in advance! Regards, Ada
