Skip to main content

Unsupported Content-Type: text/xml; charset="utf-8"

8 replies [Last post]
radovana
Offline
Joined: 2009-03-24
Points: 0

I use Metro 1.4, JDK 1.5, Tomcat 5.5 and SOAP 1.2. By every request I have becoming a following exception in catalina.out:

Unsupported Content-Type: text/xml; charset="utf-8" Supported ones are: [application/soap+xml]
com.sun.xml.ws.server.UnsupportedMediaException: Unsupported Content-Type: text/xml; charset="utf-8" Supported ones are: [application/soap+xml]
at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:295)
at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:129)
at com.sun.xml.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:287)
at com.sun.xml.ws.transport.http.HttpAdapter.decodePacket(HttpAdapter.java:276)
at com.sun.xml.ws.transport.http.HttpAdapter.access$500(HttpAdapter.java:93)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:456)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)
at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Unknown Source)

I have used the Metro logging to watch the communication between client and server. In every request and every response I have following Content-type: application/soap+xml;charset=utf-8 or Content-Type: application/xop+xml;charset=utf-8;type="application/soap+xml".
That's why I don't understand this error with the Content-Type text/xml. Can you help me please?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
grifmeister
Offline
Joined: 2006-10-18
Points: 0

I had this exact same problem. I think you will find, if you append "?wsdl" to your client web service address, the error will go away ;-)

I discovered this myself, and then did a search and found the answer here also

https://community.jboss.org/thread/1076

spamfoodie
Offline
Joined: 2011-02-23
Points: 0

I had the same problem.

The solution in my case was to add the "?wsdl" to the end of wsdlLocation URL (client side - new MyService(URL wsdlLocation, QName serviceName) ).

acuster
Offline
Joined: 2008-11-21
Points: 0

Hey,

These errors are related to SOAP 1.1 or 1.2 versions:
SOAP 1.1 uses text/xml
SOAP 1.2 uses application/soap+xml

It seems one component of your setup is sending SOAP 1.1 while the other is expecting SOAP 1.2. You will have to hunt around to find which piece to change.

good luck,
--adrian

radovana
Offline
Joined: 2009-03-24
Points: 0

I think, I set everything to SOAP 1.2. I have attached a sevrver-client communication, my WSDL and here is also my sun-jaxws.xml:


name="FormDataService"
implementation="de.bolsys.netcon.gatewaydb.wsdl.DefaultFormDataService"
wsdl="WEB-INF/wsdl/netgateway.wsdl"
binding="http://java.sun.com/xml/ns/jaxws/2003/05/soap/bindings/HTTP/"
url-pattern="/FormDataService"
enable-mtom="true"/>

My service annotations:
@WebService(name = "formDataPortType", targetNamespace = "http://bolsys.de/netcon/gatewaydb/wsdl")
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@BindingType(value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING)
@XmlSeeAlso({
ObjectFactory.class
})

My client annotations:
@WebServiceClient(name = "FormDataService", targetNamespace = "http://bolsys.de/netcon/gatewaydb/wsdl")

Did I forget anything?

yswangw
Offline
Joined: 2008-09-17
Points: 0

I have same problem with one of my web services. Here is the solution

It is because your wsdl using soap11 binding, you can either change the binding to soap12
like this " xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap12/"

or simply remove binding="http://java.sun.com/xml/ns/jaxws/2003/05/soap/bindings/HTTP/" from your deploy descriptor

radovana
Offline
Joined: 2009-03-24
Points: 0

I have already removed the binding attribute from my deploy descriptor and I still become the same exception.
In wsdl I use SOAP 1.2 (you can see it in my attachment netgateway.wsdl row number 4 - xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"). Where do you have seen I use SOAP 1.1?

jitu
Offline
Joined: 2003-06-14
Points: 0

HTTP traffic looks OK. Are you sure you are not looking at the older catalina.out output ?
Also, just use @MTOM instead of MTOM binding id.

radovana
Offline
Joined: 2009-03-24
Points: 0

I am sure I look at the actual catalina.out. The application is alredy installed on 3 servers with the same behaviour.
Using @MTOM or mtom binding id or even not using MTOM feature has no influence on the exception.
I have found out, when I use the SSL User Token Authentification (see attachment), then the exception disappears. But the application should run also by no secure (HTTP) communication without annoiyng messages.