axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eran Chinthaka <>
Subject Re: axis2 bad header for soap calls
Date Fri, 07 Sep 2007 04:10:38 GMT
Hash: SHA1


Content type for SOAP 1.1 and 1.2 are clearly defined in respective
specifications. application/xml is not defined in them. So when Axis2
engine receives a message with the content type not defined in either of
SOAP specs, it treats that as a REST call.

In that case, Axis2 engine tries to find the operation and service the
message is targeted to (this is called dispatching) using the request
url. Your request url doesn't contain enough information to identify the
service and operation and that is why you were getting that fault.

When you change the content type to text/xml, that is the content type
defined for SOAP 1.1. Then Axis2 engine treats that as a SOAP call and
uses the other means of dispatching, in addition to request URI based
dispatching. I assume the message you sent must have got some "clues"
for that. And that should be why it was successful.

You can not change Axis2 to accept custom content types as SOAP calls.
Let's see whether SOAP 1.3 helps us in that ;)


axelspin wrote:
> POST /axis2/services/resources HTTP/1.1
> Host: bsfso1:9080
> this is the http header of the ajax client I am using, it worked fine with
> axis1
> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:
> Gecko/20070725 Firefox/
> Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: en-gb,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: close
> X-Requested-With: XMLHttpRequest
> X-Prototype-Version: 1.3.1
> Content-Type: application/xml
> SOAPAction: ""
> Referer: http://localhost:9080/axis2/ajaxclient.html
> Content-Length: 154
> Cookie: JSESSIONID=529D0FE433A10635D62CAEB7082256C5
> Pragma: no-cache
> Cache-Control: no-cache
> Leaving it like this makes axis2 1.2 to reply in this way
> <faultstring>The endpoint reference (EPR) for the Operation not found is
> /axis2/services/resources and the WSA Action = null</faultstring>
> if I change the Content-Type form application/xml to text/xml all works
> fine..
> Is it a regular behaviour? would it be possible to accept as soapcalls also
> calls with Content-Type: application/xml and empty SOAPAction: ""? or such a
> client header has to be deprecated and not used at all? 
> thanks

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message