I'm trying to call a REST service from within WSO2ESB. The request needs to contain an authentication code, which will get computed based on some values including the Date transport header, which must also be part of the transport headers.
<syn:property name="Date" value="Mi, 1 Mrz 2015 11:00:00 MEZ" scope="transport" />
<syn:property name="X-Auth-Code" value="SomeCodeBasedOnDateHeader" scope="transport" />
<syn:send>
<syn:endpoint>
<syn:http uri-template="http://localhost:8280/rest/resourceA/{uri.var.resA}/resourceB/{uri.var.resB}" method="POST" />
</syn:endpoint>
</syn:send>
But when trying to send the request, the Date transport header will get removed by WSO2 ESB (The REST service will not get any Date header). Is there any chance to include the Date Header?
You can preserve the date by adding the following property to
D:\stack\wso2am-2.1.0\repository\conf\nhttp.properties
D:\stack\wso2am-2.1.0\repository\conf\passthru-http.properties
http.headers.preserve=Date
It seems that thoses headers are removed in both, NIO and Passthrough http transports :
Connection
Transfer-Encoding
Date
Content-Length
Keep-Alive
Server
User-Agent
You can preserve Server and User-Agent headers, setting http.server.preserve=true or http.user.agent.preserve=true in ESB_HOME/repository/conf/nhttp.properties or passthru-http.properties depending on which transport is configured in axis2, but it looks like there is no property to preserve Date header : you may be required to write your own http transport sender and configure your custom class in ESB_HOME/repository/conf/axis2/axis2.xml : <transportSender name="http" class="sss">
Related
Hi I am having use case that I want to validate the content-type from request (Validate incoming request ie it has to be xml only if it is other than xml it has to print please check the content). How can we achieve this in mule4
You can get the content-type header from the attributes of the request.
Example
<flow name="testContentType">
<http:listener doc:name="Listener" config-ref="HTTP_Listener_config" path="/"/>
<logger message="Content-type: #[attributes.Headers['content-type']]"/>
</flow>
You can use the same expression in a choice router or use the value to compare to a specific MIME type in a validator.
In the Mirth REST API found on EG https://localhost:8443/api/, under Channel Groups, there's a test section for bulkUpdate, which has two parameters: channelGroups, and removedChannelGroupIds. By default I set override to true.
Despite passing channelGroups and the ID list in various formats (EG as a channelGroup XML object, list of channels, list of channelGroups etc) Mirth rejects those formats and I have no idea what format Mirth is after. Leaving either field blank also fails. Does anyone have an example of a minimal working dataset for both fields that will return success from Mirth when calling bulkUpdate?
Mirth version is 3.6.0, but ideally it should also work in 3.5.1 for legacy devices.
This was answered on the user forum https://www.mirthcorp.com/community/forums/showthread.php?t=218606
That route actually expects multipart/form-data. So for example you could send a request with "Content-Type: multipart/form-data; boundary=abc123" and a payload like:
--abc123
Content-Type: application/xml; charset=utf8
Content-Disposition: form-data; name="channelGroups"
<set>
<channelGroup version="3.6.1">
<id>56a61dfb-58df-4286-8100-5ccab05364ba</id>
<name>Group 1</name>
<revision>1</revision>
<lastModified>
<time>1537550138646</time>
<timezone>UTC</timezone>
</lastModified>
<description></description>
<channels/>
</channelGroup>
</set>
--abc123
Content-Type: application/xml; charset=utf8
Content-Disposition: form-data; name="removedChannelGroupIds"
<set/>
--abc123--
As of mirth 3.6, it is not possible to call this API function from the SwaggerUI.
It also seems to be failing to create the channels within the channel group.
I'm using v2.6.2 of the Citrus Framework to write automated tests for a rest end point using the http module. Citrus is appending charset=UTF-8 to the Content-Type header. The server is responding 415 Unsupported Media due to the charset being present.
I cannot modify the rest end point.
Can I configure Citrus and the http module to not append the charset?
This was related to Citrus Http message converter always adding the default charset "UTF-8"which is set as attribute on the citrus-http:client component. So you need to overwrite the Content-Type explicitly in each send operation in order to not add the default charset.
Since Citrus 2.7.2 you can set the charset on the citrus-http:client component to an empty string. This fixes the charset appendix.
I am calling a SOAP web service as client.
Following is content-type value of response
Content-Type: text/xml
I requested customer to add UTF-8 to response as follow:
Content-Type: text/xml;charset=utf-8
But customer says that it can be from client side. Is this possible? Can I determine content type of server as client?
PS: I noticed that the cited RFC2376 is obsolete by RFC3023 (conservative enough) and then RFC7303 that I'm omitting to evaluate now in involved current use and content, so the relevance of the following might not be that definitive, I'm feeling to delete it.
You have everything formal in RFC2376 XML Media Types: Section 3.1 text/xml Registration
See also Section 6 Examples of that RFC, particularly Section 6.4 text/xml with Omitted Charset
The server side (your customer) is STRONGLY RECOMMENDED to use charset parameter that they are not currently using.
And if charter is omitted XML processors MUST use the default charset value of "us-ascii"
You are right asking the customer to specify charset, the "MUST" in the RFC is a strong requirement that limits also your adaptability from client side when they are not sending us-ascii.
I've written a CF10 RESTful web service that accepts a POST from a third party. The POST comes in with successfully with proper headers showing that it's content-type is application/json and content-encoding is gzip.
The body however comes in like this
??VJ.-.??M-?LQ?R22?0W?Q??Os-????b??????_?ZT??175 ????T?E???r??KKJ??3??S]A?#u??%??`?f??FJ???`?
The issue is that in the receiving function the cfargument for body is set to type="string" when really what it should be is type="binary". Unfortunately setting the type to binary causes the call to fail. The calling server receives the following:
Notification response HTTP/1.1 500 Internal Server Error
Content-Length: 41 Content-Type: text/plain Server: Microsoft-IIS/7.5
CF_TOMCAT_REUSE_THIS_CONNECTION: FALSE X-Powered-By: ASP.NET Date:
Thu, 30 May 2013 19:53:17 GMT Connection: close
{"Message":"Variable BODY is undefined."}
I have no control of the third party call to my REST endpoint.
Does anyone have any ideas that would allow my REST endpoint to receive this gzipped (binary) body? Alternatively, does anyone know how to convert the string representation back into a gzip'd binary that can then be inflated and I can then recover the json packet?
My code looks like this:
<cffunction name="trigger" access="remote" returntype="string" httpmethod="POST">
<cfargument name="body" type="any" >
<cfargument name="Length" type="String" restArgsource="Header" restargname="Content-Length" >
<cfargument name="Type" type="String" restArgsource="Header" restargname="Content-Type">
<cfargument name="Encoding" type="String" restArgsource="Header" restargname="Content-Encoding" >
<cfset var result = "HTTP/1.1 200 OK" >
<!--- Do some processing here --->
<cfreturn result>
</cffunction>
Thank you all in advance.
Just to add some additional input here, I did submit a bug request as attempting to change the web.xml configuration file did not initially work for me. I had added additional entries into configuration file for the GZIP decoding and instead what needed to be done was to add to the existing entries the parameter value for the GZIP encoding filters.
The original-unchanged file in web.xml should show entries such as this, found under the servlet named CFRestServlet:
<init-param>
<param-name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name>
<param-value>coldfusion.rest.servlet.CFUriConnegFilter;coldfusion.rest.servlet.CFRequestFilter</param-value>
</init-param>
<init-param>
<param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>
<param-value>coldfusion.rest.servlet.CFResponseFilter</param-value>
</init-param>
In order to enable the gzip filters, update these two parameters to have them to appear this way instead:
<init-param>
<param-name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name>
<param-value>coldfusion.rest.servlet.CFUriConnegFilter;com.sun.jersey.api.container.filter.GZIPContentEncodingFilter;coldfusion.rest.servlet.CFRequestFilter</param-value>
</init-param>
<init-param>
<param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>
<param-value>coldfusion.rest.servlet.CFResponseFilter;com.sun.jersey.api.container.filter.GZIPContentEncodingFilter</param-value>
</init-param>
As you'll see, you simply need to add the "com.sun.jersey.api.container.filter.GZIPContentEncodingFilter" as another value to the semi-colon separated list of values. Once you've made the changes, restart your CF server and then your REST based services will properly and automatically decode any GZip encoded data they receive.
For reference, my bug request can be read here: https://bugbase.adobe.com/index.cfm?event=bug&id=3694176
Thanks.
If I understand your problem correctly, this can be done with GZIPContentEncodingFilter
In short CF's rest support is built upon JERSEY APIs. When a request comes to a rest endpoint (defined in the URL), a series of jersey filters execute before invoking the actual function. This is where this filter would execute and handle GZIP compression for you.
You may configure only the request filter (In case the library is not expecting a gzipped response back). Just add following in web.xml and hopefully will be done.
<init-param>
<param-name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name>
<param-value>com.sun.jersey.api.container.filter.GZIPContentEncodingFilter</param-value>
</init-param>
CF already has one filter added for handling *.json & *.xml requests.
HTH,
Chandan Kumar
GZip encoding support added in CF11: https://wikidocs.adobe.com/wiki/display/coldfusionen/RESTful+Web+Services+in+ColdFusion#RESTfulWebServicesinColdFusion-SupportforGZipencoding