Our client is sending a http post request at our int:http inbound gateway which has the following signature:-
<int:channel id="http-Input-channel"/>
<int:channel id="http-Output-channnel"/>
<int-http:inbound-gateway id="HttpInboundGateway"
supported-methods="POST,GET"
request-payload-type="java.lang.String"
request-channel="http-Input-channel"
reply-channel="http-Output-channnel"
path="/Response.do"
mapped-request-headers="*"/>
<int:service-activator input-channel="http-Input-channel" ref="ResponseHandler" output-channel="http-Output-channnel" method="handleMessage"/>
</beans>
thus,i am receiving the message via the int:inbound gateway in the service activator's(which is the ResponseHandler bean) method handleMessage() as follows:
public Message handleMessage(Message message) {}
the message contains the results and having the base64 string of the pdf.
when i am debugging i found that the message comes as in the encoded form and content type as 'content-type => application/x-www-form-urlencoded'.
In order to get the actual payload i have to decode that which causes the '+' in the format sent by the client to replace with the space in the whole XML.
if i replace all the spaces with the '+' sign again all works well.i can see the correct format for the whole base64 string of pdf and it opens.
However this is not the actual fix.as client is not sending us the content-type => application/x-www-form-urlencoded in the headers. they are sending that as the content-type => 'text/xml'.
my question is why the int:http inbound gateway changes the content type and encoded the result XML.can we change content type to 'text/xml' of the int http inbound gateway in its configuration before it actually hits the service activator and start processing the XML.
i tired using the message converters but it just duplicates the content type and give preference the application/x-www-form-urlencoded.
can you please suggest what should be used along with the int:http inbound gateway in order to get the result XML having the text/xml as the content type and result XML not in the encoded form.i think changing the content type will solve the problem.but how??
Thanks
dev
Related
I have noticed that rest doc (HttpRequestSnippet.java) is setting APPLICATION_FORM_URLENCODED_VALUE as content type for PUT with request parameter and without request body. This should be corrected, may be introducing a MEDIATYPE as NONE and set content type as NONE or ALL when request body/content empty.
For example, my put request is like below:
/api/v1/config/?mode=unknow
This sounds like a bug in Spring REST Docs' HttpRequestSnippet for which I've opened an issue.
I'm new to OneM2M Protocol.
Searching for the OneM2M TS0001 documents, I don't get any idea of determining the Notification MIME type.
How do I determine MIME type(e.g. 'application/json', 'application/xml') of notification?
I couldn't find anything in Subscription's attributes.
This is an example of application developer guide from the site below. How did they decide to send this notification as the type of 'application/xml'?
Post a notification to ADN-AE1
HTTP Request with XML payload
POST / HTTP/1.1
Host: 192.168.0.10:9090
X-M2M-Origin: /mn-cse
X-M2M-RI: notif-12345
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8"?>
<m2m:sgn xmlns:m2m="http://www.onem2m.org/xml/protocols" rn="cin-394798749">
<nev>
<rep>
<m2m:cin>
<ty>4</ty>
<ri>cin-394798749</ri>
<pi>cnt-790965889</pi>
<ct>20150925T050534</ct>
<lt>20150925T050534</lt>
<et>20151107T154802</et>
<st>0</st>
<cnf>text/plain:0</cnf>
<cs>3</cs>
<con>ON</con>
</m2m:cin>
</rep>
</nev>
<sur>/mn-cse/sub-856593979</sur>
</m2m:sgn>
http://www.onem2m.org/application-developer-guide/implementation/notifications
You should have a look at TS-0004 "Service Layer Core Protocol Specification", section 6.7 "oneM2M specific MIME media types". There you can find all the oneM2M specific MIME types.
According to that table, the correct MIME type for a notification and XML encoding is application/vnd.onem2m-ntfy+xml.
That said, you might also check TS-0009 "HTTP Protocol Binding", sections 6.4.2 "Accept" and 6.4.3 "Content-Type". Here, the specification says, for example for Content-Type:
Any HTTP request or response containing message-body shall include the Content-type header set to one of “application/xml”, “application/json”, or the oneM2M defined media types defined in clause 6.7 of oneM2M TS-0004.
Since one can determine unambiguously the type of the resource by looking at the element *m2m:sgn", setting *application/xml" as the Content-Type for XML encoded resources is usually enough.
You can download the latest versions of the oneM2M specifications at http://www.onem2m.org/technical/published-drafts
Update
The CSE determines the encoding type (xml, json or cbor) for the notification message by looking at the optional ty parameter of the notificationURI attribute.
This is specified in TS-0001, section 9.6.8 "Resource Type subscription". The subscriber of a notification can add a type parameter (e.g. ty=xml) to the notificationURI. If this is left out, then the CSE chooses a default encoding.
I'm trying to receive a json payload on a hapijs server, that json may not be valid, since is some custom format that i need to manually proxy the request to an elasticsearch cluster, cannot use the proxy option for hapijs because i need to do multiple requests to different clusters, for that i use nodejs http library.
Elasticsearch doesn't receive a valid json when doing bulk actions, it receives new lines instead of commas, to separate json objects:
{"index":[".kibana-devnull"],"ignore_unavailable":true}
{"size":500,"sort":[]}
Hapijs tries to validate the json payload when it gets application/json header in the request and it responds "Invalid request payload JSON format", as i cannot remove that header i need to look for another method to allow that invalid json in the route, even if the header is present.
I would look at the docs, in particular http://hapijs.com/api#route-configuration. If you set payload.output.parse to false you will receive the raw buffer inside handler which can then be parsed by yourself as opposed to by the framework.
I have a mirth instance (version 3.0.1) sending out using a POST method to a web api restfull service.
[POST("MessagesHl7/OML_O21")] public HttpResponseMessage
PostOmlo21([FromBody] sting receivedmessage) {..}
The problem is that the message hl7 that is sent to the service
in a outbound message is cut in the first characters. For example, in the message:
MSH|^~\&|CPSI^1.3.6.1.4.1.27248.1.17^ ISO|CGH|...
in the receivedmessage variable the text MSH|^~\ is received only.
How can I do in order that the message is not cut?
In the http channel, the configuration is:POST, not query parameters,
in
headers content-type application/x-www-form-urlencoded,
Content-Type value application/xml,
and the value that send is =${message.encodedData}.
Change your action method to not use binding and just read the request body as string.
[POST("MessagesHl7/OML_O21")]
public Task<HttpResponseMessage> PostOmlo21()
{
string receivedMessage = await Request.Content.ReadAsStringAsync();
}
I would suggest to use Base64 encoding for the HL7 piped message since
there are many special characters within the message which can be interpreted
in the wrong way during parsing. Especially during the parsing of xml.
Of course you have to decode the HL7 message on Server side.
But i think Mirth gives you all functionallity to do that.
I don't know which class to use in C#/ASP in Java appropriate classes and frameworks for
encoding an decoding Base64 exist. I believe the same is true for C# and ASP.
I am using JMeter to do load-testing. My test consists of a simple POST request. When I perform this request, the server, in its error logs, says No Payload Detected. I have verified that the server is receiving a Post request, and I have tried different texts in the Raw Post Body.
Next, to make sure it wasn't a problem with the server, I used a different Http Request program (Wiztools rest client) to send off a post with the same content. It works, and no No Payload Detected error is thrown.
My current theory is that both JMeter and the server do parsing. I know the server does, as it is looking for a small piece of data, and that JMeter's parsing ruins that small piece of data.
So, in conclusion, my question is "What parsing does JMeter do?".
I've looked for this answer, and the only thing I know that it does parse is ${VARNAME}.
The text I am sending is below:
<IpReport xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="">
<ProductReviewId>12345</ProductReviewId>
<DepartmentCode>ABC</DepartmentCode>
<ProductTitle>Test of a teaser</ProductTitle>
<ProjectId>2</ProjectId>
<ProductCodePD>ICS-1139150</ProductCodePD>
<Priority>Pre-Approved</Priority>
<Status>Approved</Status>
<IpStatus>Submitted</IpStatus>
<EvalStatus>Approved</EvalStatus>
<EvalNotes>No Limitations - message from eval</EvalNotes>
<Notes>Notes test</Notes>
<IsInClarity>true</IsInClarity>
<IsPreRelease>true</IsPreRelease>
<IsApproved>true</IsApproved>
<IsCOREvalIP>false</IsCOREvalIP>
<Elements>
<IpReportElement>
<IpReportElementLineItemId>21774</IpReportElementLineItemId>
<ElementType>ReportingStatement</ElementType>
<Contributor>Sample Contributor</Contributor>
<Description>test</Description>
<LocationInProduct>test</LocationInProduct>
<ReportingStatementId>7</ReportingStatementId>
<IpCodeId>3</IpCodeId>
<Links>
<IpReportLink>
<IpReportLinkId>25982</IpReportLinkId>
<Name>Link</Name>
<Url>https://example.org/</Url>
</IpReportLink>
</Links>
</IpReportElement>
</Elements>
<CustomData><site>ldsorg</site>
<site-root>/preview/ldsorg/</site-root>
<correlation-document-id>123456-eng</correlation-document-id>
<post-to-server>l12773:9239</post-to-server>
</CustomData>
<ApprovalNumber>2013-1139150-I</ApprovalNumber>
<EvalApprovalNumber>2013-1139150-E</EvalApprovalNumber>
</IpReport>
Here is an screenshot of JMeter. This is the only request, with no other config elements:
You may also need to add an HTTP Header Manager as a child of HTTP Request to set some header like content-type:
First of all. In your question above, both in screenshot and in request text part of request has symbols < and > encoded and part - not. And you are using Content Encoding = UTF-8 in addition. Seems that in this situation request will be sent malformed.
You can add e.g. View Results Tree listener and check how the request is sent from jmeter.
You can try dedicated REST Sampler as well.