• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Axis2 returning http 500 instead of http 400 on invalid request

Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Folks,
I have a simple web service implemented using jax-ws which uses axis2 (java 1.6) implementation. When a valid request is sent the service responds back with expected response and HTTP 200.  
But when the soap message posted to the service is blank then I expect a soap fault with http 400 as Bad Request. But instead service responds with HTTP 500 as below

HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset=UTF-8
Content-Language: en-US
Content-Length: 352
Connection: Close
Date: Mon, 11 Jul 2016 09:09:12 GMT
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body>;
        <faultstring>javax.xml.stream.XMLStreamException: The root element is required in a well-formed document.</faultstring>

How do I enforce axis2 to return HTTP 400 in this case of blank SOAP request than http 500 which is misleading? I browsed through lot of articles but no luck. Greatly appreciate your time.

The ffdc log has the below trace:
org.apache.axis2.AxisFault: javax.xml.stream.XMLStreamException: The root element is required in a well-formed document.
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:283)
at com.ibm.ws.websvcs.transport.http.WASAxis2Servlet.doPost(WASAxis2Servlet.java:1444)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:738)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1667)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:944)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:507)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:181)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:91)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:878)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1592)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:191)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1660)
Caused by: org.apache.axiom.om.OMException: javax.xml.stream.XMLStreamException: The root element is required in a well-formed document.
at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:255)
at org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.getSOAPEnvelope(StAXSOAPModelBuilder.java:156)
at org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.<init>(StAXSOAPModelBuilder.java:105)
at org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:60)
at org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:191)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:139)
at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:270)
... 25 more
Caused by: javax.xml.stream.XMLStreamException: The root element is required in a well-formed document.
at com.ibm.xml.xlxp2.api.stax.msg.StAXMessageProvider.throwWrappedXMLStreamException(StAXMessageProvider.java:76)
at com.ibm.xml.xlxp2.api.stax.XMLStreamReaderImpl.produceFatalErrorEvent(XMLStreamReaderImpl.java:2013)
at com.ibm.xml.xlxp2.api.jaxb.JAXBXMLStreamReader.produceFatalErrorEvent(JAXBXMLStreamReader.java:316)
at com.ibm.xml.xlxp2.scan.DocumentScanner.reportFatalError(DocumentScanner.java:4886)
at com.ibm.xml.xlxp2.scan.DocumentScanner.reportFatalError(DocumentScanner.java:1213)
at com.ibm.xml.xlxp2.scan.DocumentScanner.scanProlog(DocumentScanner.java:1774)
at com.ibm.xml.xlxp2.scan.DocumentScanner.nextEvent(DocumentScanner.java:1324)
at com.ibm.xml.xlxp2.api.stax.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:586)
at com.ibm.xml.xlxp2.api.stax.XMLInputFactoryImpl$XMLStreamReaderProxyImpl.next(XMLInputFactoryImpl.java:183)
at com.ibm.xml.xlxp2.api.wssec.WSSXMLInputFactory$WSSStreamReaderProxy.next(WSSXMLInputFactory.java:55)
at org.apache.axiom.om.impl.builder.StAXBuilder.parserNext(StAXBuilder.java:567)
at org.apache.axiom.om.impl.builder.StAXOMBuilder.nextToken(StAXOMBuilder.java:634)
at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:175)
... 31 more
Author and all-around good cowpoke
Posts: 13078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If by blank request, you mean one with no body, isn't the 500 exactly what you would expect?
Curious Java
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for the reply. HTTP 500 means internal server error. But in this case it's the bad request (where there is no body in SOAP) which is causing that error. So I believe the calling service should be given 400 so that they can handle.

With HTTP 500 the calling service can assume it's the webservice issue when it is not.
William Brogden
Author and all-around good cowpoke
Posts: 13078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I suspect this error is thrown very early in the SOAP process, way before your SOAP code has any chance to catch it.
Curious Java
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That maybe true. I tried catching it as part of soap handler chains but didn't work. So not sure how else I could achieve this. Should I switch to CXF? Any other alternatives?
Ranch Hand
Posts: 729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is true that HTTP status code looks inviting all sorts of arguing one way or another their exact meaning and inspiring all sorts of imagination... For this case where the server is in a position to return a response in a two-way messaging service with soap fault (modeled or not), I would argue that practically all providers would raise a HTTP status code of 500. The reason is that they would rather converge to the industrial common practice. That practice is specified in SOAP 1.1 w3c note and again be accepted in verbatim by the WS-I Basic Profile 1.1. It is recommended :

SAOP 1.1 wrote:
R1126 An INSTANCE MUST return a "500 Internal Server Error" HTTP status code if the response envelope is a Fault.

So I doubt a switch to CXF would change anything in this particular regard. Even if you work on the ws server implementor level rather than just application developer level, it would a big deal decision if you want to stand out that way against. Besides, the fault string conveys good info as far as I can see for this case. But it is up to you.
Don't get me started about those stupid light bulbs.
    Bookmark Topic Watch Topic
  • New Topic