HTTP POST not fully supported?

73 views
Skip to first unread message

Guenther Schreiner

unread,
Oct 11, 2012, 4:46:54 AM10/11/12
to membrane...@googlegroups.com
Hello together,

we're using the membrane-esb-3.2.4 for SOAP proxying and in addition for one HTTP redirection.
All of the SOAP processing is doing well (thanks team, good work!) but the HTTP part fails under
some circumstances. We have identified the POST processing as one possible fault:

Internal Server Error

While processing your request, the following error was detected. Stack traces can be disabled by setting the @printStackTrace attribute on transport. More details might be found in the log.

org.xml.sax.SAXParseException: Content is not allowed in prolog.
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at com.sun.org.apache.xpath.internal.jaxp.XPathImpl.evaluate(Unknown Source)
at com.predic8.membrane.core.interceptor.cbr.XPathCBRInterceptor.findRoute(XPathCBRInterceptor.java:73)
at com.predic8.membrane.core.interceptor.cbr.XPathCBRInterceptor.handleRequest(XPathCBRInterceptor.java:54)
at com.predic8.membrane.core.interceptor.InterceptorFlowController.invokeRequestHandlers(InterceptorFlowController.java:94)
at com.predic8.membrane.core.interceptor.UserFeatureInterceptor.handleRequest(UserFeatureInterceptor.java:41)
at com.predic8.membrane.core.interceptor.InterceptorFlowController.invokeRequestHandlers(InterceptorFlowController.java:94)
at com.predic8.membrane.core.interceptor.InterceptorFlowController.invokeHandlers(InterceptorFlowController.java:60)
at com.predic8.membrane.core.transport.http.AbstractHttpHandler.invokeHandlers(AbstractHttpHandler.java:65)
at com.predic8.membrane.core.transport.http.HttpServerHandler.process(HttpServerHandler.java:179)
at com.predic8.membrane.core.transport.http.HttpServerHandler.run(HttpServerHandler.java:87)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
--------------- linked to ------------------
javax.xml.xpath.XPathExpressionException
at com.sun.org.apache.xpath.internal.jaxp.XPathImpl.evaluate(Unknown Source)
at com.predic8.membrane.core.interceptor.cbr.XPathCBRInterceptor.findRoute(XPathCBRInterceptor.java:73)
at com.predic8.membrane.core.interceptor.cbr.XPathCBRInterceptor.handleRequest(XPathCBRInterceptor.java:54)
at com.predic8.membrane.core.interceptor.InterceptorFlowController.invokeRequestHandlers(InterceptorFlowController.java:94)
at com.predic8.membrane.core.interceptor.UserFeatureInterceptor.handleRequest(UserFeatureInterceptor.java:41)
at com.predic8.membrane.core.interceptor.InterceptorFlowController.invokeRequestHandlers(InterceptorFlowController.java:94)
at com.predic8.membrane.core.interceptor.InterceptorFlowController.invokeHandlers(InterceptorFlowController.java:60)
at com.predic8.membrane.core.transport.http.AbstractHttpHandler.invokeHandlers(AbstractHttpHandler.java:65)
at com.predic8.membrane.core.transport.http.HttpServerHandler.process(HttpServerHandler.java:179)
at com.predic8.membrane.core.transport.http.HttpServerHandler.run(HttpServerHandler.java:87)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.xml.sax.SAXParseException: Content is not allowed in prolog.
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown Source)
... 13 more

Any ideas about this issue?

With best regards,
Guenther

--
University of Applied Sciences Karlsruhe / Information Center (IZ)
Moltkestrasse 30
76133 Karlsruhe/Germany
Web: www.hs-karlsruhe.de/iz



Thomas Bayer

unread,
Oct 11, 2012, 4:59:48 AM10/11/12
to membrane...@googlegroups.com, guenther....@hs-karlsruhe.de
Hi Guenther,
thanks for the error report. I am glad to help you. The error message you got: 

Content is not allowed in prolog. 

is a clue that the body of your POST request contains some characters before the XML content.  Maybe it is an error in Membrane. What I need to find out is a log message of the request. Maybe you can place a <log/> element before the content based router and have a look into the log file. Please cut out the request if possible and post it to the list. If it is confidential please send it to our company address in...@predic8.de.

--
Thomas

Guenther Schreiner

unread,
Oct 11, 2012, 10:04:54 AM10/11/12
to Thomas Bayer, membrane...@googlegroups.com

Hello Thomas,

 

the http proxy works fine up to the point where a POST is sent from the client.

 

The famous last words of the http conversation are coming from the originating client side:

 

POST /otrs/index.pl HTTP/1.1

Host: 193.196.65.141

User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0.1

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate

DNT: 1

Connection: keep-alive

Referer: http://193.196.65.141/otrs/index.pl

Content-Type: application/x-www-form-urlencoded

Content-Length: 82

Action=Login&RequestedURL=&Lang=de&TimeOffset=-120&User=demo&Password=demoPassword

 

Taking  a look into the network trace, the membrane is just closing the connection.

 

With best regards,

   Guenther

 

--

University of Applied Sciences Karlsruhe / Information Center (IZ)

Moltkestrasse 30

76133 Karlsruhe/Germany

Web: www.hs-karlsruhe.de/iz

 

http-proxy-20121011.pcap

Thomas Bayer

unread,
Oct 11, 2012, 10:29:40 AM10/11/12
to membrane...@googlegroups.com, Thomas Bayer, guenther....@hs-karlsruhe.de
Hi Guenther,
thanks for the captured message. The content type of your request is application/x-www-form-urlencoded and not XML. In your serviceProxy you use a content based router with an XPath expression. XPath can only be applied to XML. So the XML parser tries to  parse the message and fails. We will test for the content-type in the CBR and provide a more meaningful message in the future.

Maybe you can post your serviceProxy configuration and describe shortly what you want to do exactly. We are glad to help you and to extend the functionality of Membrane if needed.

--
Thomas


Guenther Schreiner

unread,
Oct 11, 2012, 10:45:19 AM10/11/12
to Thomas Bayer, membrane...@googlegroups.com
Hi Thomas,

The following service definition works well for HTTP GETs but not for HTTP POSTs:

<serviceProxy name="OTRS" port="443" inboundTLS="true" >
<path isRegExp="false">/otrs</path>
<switch>
<case xPath="/otrs/" url="//internalhost/otrs/" />
<case xPath="/otrs-web/" url="//internalhost/otrs-web/" />
</switch>
<target host="internalhost" port="80"/>
<statisticsCSV file="OTRS-log.csv"/>
</serviceProxy>

Of course, with your explanation it is obverse: eliminating the xpath related statements
(resp. the <switch> statement) from the serviceProxy definition, the HTTP GET
and POST operations succeed.

The real strange behaviour was, that all GET operations did not lead to an error?

Thanks for your help!

Thomas Bayer

unread,
Oct 11, 2012, 11:02:46 AM10/11/12
to membrane...@googlegroups.com, Thomas Bayer, guenther....@hs-karlsruhe.de
Hi Günther,

the GET worked because a GET does not have a message body. Without a message body the content based router does nothing. Looking at your configuration I guess that you want to route based on the URI of a request. You can achieve this by simply using multiple serviceProxy definitions. Your configuration will then look like:

<serviceProxy name="OTRS" port="443" inboundTLS="true" > 
    <path isRegExp="false">/otrs</path> 
    <statisticsCSV file="OTRS-log.csv"/> 

     <target host="internalhost" port="80"/> 
</serviceProxy> 


<serviceProxy name="OTRS-WEB" port="443" inboundTLS="true" > 
    <path isRegExp="false">/otrs-web</path> 
    <statisticsCSV file="OTRS-WEB-log.csv"/> 

     <target host="internalhost" port="80"/> 
</serviceProxy> 

The first proxy that matches will win and route the message. The decission can be made by URL, port, hostname ... 
If that is not solving your problem, please let me know.

--
Thomas

Reply all
Reply to author
Forward
0 new messages