How to resolve Error while building Passthrough stream java.util.zip.ZipException in WSo2 Gateway? - api

I am getting the following error on the WSo2 Gateway 2.1.0 when trying to pass a response back to WSo2 EI that originated an API call on APIM and I am not sure what the issue is:
[2021-05-06 15:19:26,401] ERROR org.apache.synapse.transport.passthru.util.RelayUtils:344 - Error while building Passthrough stream
java.util.zip.ZipException: Not in GZIP format
at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:165)
at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:79)
at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:91)
at org.apache.axis2.transport.http.HTTPTransportUtils.handleGZip(HTTPTransportUtils.java:262)
at org.apache.synapse.transport.passthru.util.DeferredMessageBuilder.getDocument(DeferredMessageBuilder.java:95)
at org.apache.synapse.transport.passthru.util.RelayUtils.builldMessage(RelayUtils.java:151)
at org.apache.synapse.transport.passthru.util.RelayUtils.buildMessage(RelayUtils.java:114)
at org.apache.synapse.transport.passthru.util.RelayUtils.buildMessage(RelayUtils.java:78)
at org.wso2.carbon.apimgt.gateway.handlers.LogsHandler.buildResponseMessage_aroundBody16(LogsHandler.java:264)
at org.wso2.carbon.apimgt.gateway.handlers.LogsHandler.buildResponseMessage(LogsHandler.java:254)
at org.wso2.carbon.apimgt.gateway.handlers.LogsHandler.handleResponseInFlow_aroundBody6(LogsHandler.java:141)
at org.wso2.carbon.apimgt.gateway.handlers.LogsHandler.handleResponseInFlow(LogsHandler.java:131)
at org.apache.synapse.core.axis2.Axis2SynapseEnvironment.invokeHandlers(Axis2SynapseEnvironment.java:1077)
at org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:242)
at org.apache.synapse.core.axis2.SynapseCallbackReceiver.handleMessage(SynapseCallbackReceiver.java:556)
at org.apache.synapse.core.axis2.SynapseCallbackReceiver.receive(SynapseCallbackReceiver.java:186)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
at org.apache.synapse.transport.passthru.ClientWorker.run(ClientWorker.java:265)
at org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
at datadog.trace.bootstrap.instrumentation.java.concurrent.Wrapper.run(Wrapper.java:25)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
```

There can be some possible scenarios for the above issue.
Content-Encoding: gzip header comes in the response header but the content of the response is not in GZIP format. You can verify that by enabling the wire logs.
You can get rid of this behavior by removing the Content-Encoding header using header mediator as shown below before calling the EI endpoint.
<header action="remove" name="Content-Encoding" scope="transport"/>
The client(according to your case it's EI) is expecting the content encoded as gzip while the APIM is serving it deflated or some other way.
So in such a case, You can use the below property to send the response in gzip format
<property name="Content-Encoding" value="gzip" scope="transport"/>

Related

How to test if your REST API service supports gzip data?

I am testing a REST API service that supports json and gzip data. I have tested the response from the json request payload. How to test if it handles gzip data properly? Please help?
Basically the client sends a request with accept-encoding as gzip in the header, service handles the compression and the client takes care of the decompression. But I need a way to confirm that service indeed handles compressed gzip data
gzip is basically a header + deflate + a checksum.
Gatling will retain the original Content-Encoding response header so you can check if the payload was gzipped, and then trust the gzip codec to do the checksum verification and throw an error if the payload was malformed.

Disable the default stacktrace error response in Jetty

We received a PenTest finding stating that the stack trace given from the 400 "Unable to Parse" Jetty error (below) gives the attacker too much information and we should disable that part of the error response.
I'm reading through the documentation on error handling but I'm pretty new to both eclipse and jetty. It's unclear to me what I should do.
For example I think where I make the change depends on whether or not we're using WebAppContext, but I don't know how to find out if we are using that or not.
All I've managed to do is find our web.xml file inside WEB_INF/web.xml
Here's the error response: the stack trace continues much further but I shortened here for brevity sake.
HTTP ERROR 400 Unable to parse URI query
URI:
STATUS: 400
MESSAGE: Unable to parse URI query
SERVLET: Portal
CAUSED BY: org.eclipse.jetty.http.BadMessageException: 400: Unable to parse URI query
CAUSED BY: org.eclipse.jetty.util.Utf8Appendable$NotUtf8Exception: Not valid UTF8! byte Bf in state 0
Caused by:
org.eclipse.jetty.http.BadMessageException: 400: Unable to parse URI query
at org.eclipse.jetty.server.Request.getParameters(Request.java:449)
at org.eclipse.jetty.server.Request.getParameter(Request.java:1059)
at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194)
at com.gce2000.common.servlet.CrossScriptingFilter$XSSRequestWrapper.getParameter(CrossScriptingFilter.java:94)
In your WEB-INF/web.xml just specify an HTML (or Servlet, or JSP) that can handle your error.
<web-app>
<error-page>
<!-- Bad Request -->
<error-code>400</error-code>
<location>/error-bad-request.html</location>
</error-page>
</web-app>
You can declare error-page's for status codes and Exceptions.
You might want to also declare the global one (make sure your WEB-INF/web.xml is using Servlet 3.0 or better)
<web-app>
<error-page>
<location>/error-general.html</location>
</error-page>
</web-app>

WSO2EI - Outward SOAP call fails with hostname validation

My Setup
I am using WSO2EI version 6.4.0 to host my Rest API.
My Client --> WSO2EI --> Outside SOAP Calls
I do not have set up any mutual auth/keys etc. between WSO2EI and the outside servers.
What I am doing
When my client calls me(WSO2EI), I(WSO2EI) call other SOAP endpoints (different domains) and I(WSO2EI) am a client of these endpoints.
The Issue
A call from client(postman) --> WSO2EI --> OUT_SIDE_SOAP_END_POINT_1
whereas
another call from client(postman) --> WSO2EI --> OUT_SIDE_SOAP_END_POINT_2 does not.
However, a direct call from client(postman) --> OUT_SIDE_SOAP_END_POINT_2 works
The Exception Stack
[PassThroughMessageProcessor-1] INFO {org.apache.axis2.transport.http.HTTPSender} - Unable to sendViaPost to url[https://vsb.nrt.unabdev.sprint.com/services/CloudService]
javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: null
at org.opensaml.ws.soap.client.http.TLSProtocolSocketFactory.verifyHostname(TLSProtocolSocketFactory.java:233)
at org.opensaml.ws.soap.client.http.TLSProtocolSocketFactory.createSocket(TLSProtocolSocketFactory.java:194)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.axis2.transport.http.AbstractHTTPSender.executeMethod(AbstractHTTPSender.java:704)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:199)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:81)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:459)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:286)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:442)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:442)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:149)
at org.apache.synapse.message.senders.blocking.BlockingMsgSender.sendReceive(BlockingMsgSender.java:493)
at org.apache.synapse.message.senders.blocking.BlockingMsgSender.send(BlockingMsgSender.java:385)
at org.apache.synapse.core.axis2.Axis2FlexibleMEPClient.send(Axis2FlexibleMEPClient.java:90)
#
at org.apache.synapse.core.axis2.Axis2Sender.sendOn(Axis2Sender.java:85)
at org.apache.synapse.core.axis2.Axis2SynapseEnvironment.send(Axis2SynapseEnvironment.java:547)
at org.apache.synapse.endpoints.AbstractEndpoint.send(AbstractEndpoint.java:384)
at org.apache.synapse.endpoints.DefaultEndpoint.send(DefaultEndpoint.java:77)
at org.apache.synapse.mediators.builtin.CallMediator.handleBlockingCall(CallMediator.java:164)
at org.apache.synapse.mediators.builtin.CallMediator.mediate(CallMediator.java:119)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:108)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:70)
at org.apache.synapse.mediators.template.TemplateMediator.mediate(TemplateMediator.java:104)
at org.apache.synapse.mediators.template.InvokeMediator.mediate(InvokeMediator.java:148)
at org.apache.synapse.mediators.template.InvokeMediator.mediate(InvokeMediator.java:84)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:108)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:70)
at org.apache.synapse.config.xml.AnonymousListMediator.mediate(AnonymousListMediator.java:37)
at org.apache.synapse.mediators.filters.FilterMediator.mediate(FilterMediator.java:203)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:108)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:70)
at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:158)
at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:214)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:108)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:70)
at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:158)
at org.apache.synapse.rest.Resource.process(Resource.java:358)
at org.apache.synapse.rest.API.process(API.java:426)
at org.apache.synapse.rest.RESTRequestHandler.apiProcess(RESTRequestHandler.java:135)
at org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:113)
at org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:71)
at org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:303)
at org.apache.synapse.core.axis2.SynapseMessageReceiver.receive(SynapseMessageReceiver.java:98)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
at org.apache.synapse.transport.passthru.ServerWorker.processNonEntityEnclosingRESTHandler(ServerWorker.java:337)
at org.apache.synapse.transport.passthru.ServerWorker.processEntityEnclosingRequest(ServerWorker.java:383)
at org.apache.synapse.transport.passthru.ServerWorker.run(ServerWorker.java:151)
at org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
What I have done and how they have faired
Setting System Property[ignoreHostnameVerification] on integrator.sh
-Dorg.wso2.ignoreHostnameVerification=true Same Exception
Setting System Property[hostnameVerifier & disableHostnameVerification] on integrator.sh
-Dhttpclient.hostnameVerifier=AllowAll \
-Dorg.opensaml.httpclient.https.disableHostnameVerification=true \
This did not work either.
Since the direct call from pos tman to OUT_SIDE_SOAP_END_POINT_2 works, I think OUT_SIDE_SOAP_END_POINT_2 is open and I should not have to do any settings on my WSO2EI instance.
Any thoughts and pointers are highly appreciated.
Thank you.
From your stacktrace, you seem to be using a Call mediator in blocking mode. There seems to an issue already reported with regards to Blocking transport. https://github.com/wso2/product-ei/issues/1501
Can you try out the workaround suggested in the issue?
As a workaround for this, we can disable switching to opensaml http
client by setting rampart.axiom.parser.pool=false in a server start
up. So removing from the backlog
The following combination worked. This allowed for the Apache HTTP client to take over from SAML. However, then I had to add the certificate into the client trust store.
-Dorg.wso2.ignoreHostnameVerification=true \
-Dorg.opensaml.httpclient.https.disableHostnameVerification=true \
This solve this particular problem.

When passing data to an App in mule cloudhub via API gateway(CloudHub) getting exception -HTTP header is larger than 8192 bytes

Am having an HTTP connector and a HTTPS connector which runs in API gatewayruntime in cloudhub. I want to pass the data through this API gateway to another application but while passing at the endpoint am getting
HTTP header is larger than 8192 bytes Exception
Exception stack trace: org.jboss.netty.handler.codec.frame.TooLongFrameException: HTTP header is larger than 8192 bytes. at org.jboss.netty.handler.codec.http.HttpMessageDecoder.readHeader(HttpMessageDecoder.java:596) at org.jboss.netty.handler.codec.http.HttpMessageDecoder.readHeaders(HttpMessageDecoder.java:503) at org.jboss.netty.handler.codec.http.HttpMessageDecoder.decode(HttpMessageDecoder.java:193) + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything)
Use this in connector configuration to suppress the header session
<http:connector name="NoSessionConnector" doc:name="HTTP-HTTPS">
<service-overrides sessionHandler="org.mule.session.NullSessionHandler"/>
</http:connector>

WSO2 ESB doesn't process Put request from API store

We are using WSO2 ESB 4.7.0 and WSO2 API Manager 1.6.0
I have an API defined the ESB which takes a PUT request and processes it to a back end system and sends back the response as success.
The API works fine if I use the soap client or Advanced Rest Client.
Request URL: http://:/CurriculumAdmin/Terms/2010/Classes/11513/LMSURL?LMSURL=KRanthiPUTARCAPI
Response:
Status 200 OK
But if I create a API using the WSO2 API manager and use the try it option from there, I get a 202 response
Request URL:
https://:/TestURL/v1.0/Terms/2010/Classes/11513/LMSURL?LMSURL=KranthiTestAPI
Where TestURL/v1.0 is the context root /resource for my API.
Response:
Response Body
Response Code
202
I could see that the response comes till the ESB , but the ESB doesn't do anything with the request and simply sends a response code of 202 back..
Any suggestions / help are highly appreciated.
Thanks
Kranthi
This issue occurs due to a parameter that is set by default by the WSO2 API Manager.
Go to /usr/local/wso2/wso2am-1.6.0/repository/deployment/server/synapse-configs/default/api
Open the .xml file of the corresponding API and remove the following line.
<property name="POST_TO_URI" value="true" scope="axis2"/>
This parameter is set by API manager by default. WSO2 will make a fix to their product API manager in release 1.8.0 to NOT set this property as default.
ESB Logs Before the change :
TID: [0] [ESB] [2014-10-27 11:16:18,068] DEBUG {org.apache.synapse.transport.http.wire} - >> "PUT http://:/CurriculumAdmin/Terms/2010/Classes/11513/LMSURL?LMSURL=www HTTP/1.1[\r][\n]" {org.apache.synapse.transport.http.wire}
Observer the hostname and portnumber appearing in the request sent to ESB
ESB Logs After the change :
TID: [0] [ESB] [2014-10-27 11:24:54,478] DEBUG {org.apache.synapse.transport.http.wire} - >> "PUT /CurriculumAdmin/Terms/2010/Classes/11513/LMSURL?LMSURL=www HTTP/1.1[\r][\n]" {org.apache.synapse.transport.http.wire}
Hostname and portnumber are removed from the URL.
This works fine and hence the issue is resolved. Hope its useful for someone ..
Thanks
Kranthi