I am having trouble in processing .pdf response.
Scenario - webBrowser -> DP(MPGW) -> (Backend) RESTful WebService.
DP - XI50 Firmware Version 184.108.40.206
When I hit the backend directly (via browser) - a .pdf file is returned and displayed successfully.
Now I hit the same backend, but via DataPower - I am not getting expected result.
I have all the setting and code in place for non-XML processing(I hope so).
1. I have 'non-XML' response processing turned 'ON' on response rule.
2. Then I have transformation Binary Action. - In this one I call xsl
<?xml version="1.0" encoding="utf-8"?>
<dp:input-mapping href="XYZ.ffd" type="ffd"/>
XYZ.ffd is defined as
3. In the PROBE, all the actions are not shown. I get error 'Debug: Could not connect to debugger'.
4. This is because, 'dp:parse() error: illegal character '%' at offset 0 of *dp:parse*' error.
5. Here is content of the probe. First few lines
offset Data ascii
0x000000 25 50 44 46 2d 31 2e 34 0a 25 c7 ec 8f a2 0a 35 %PDF-1.4.%.....5
0x000010 20 30 20 6f 62 6a 0a 3c 3c 2f 4c 65 6e 67 74 68 0 obj.../Lengt
0x000020 20 36 20 30 20 52 2f 46 69 6c 74 65 72 20 2f 46 6 0 R/Filter /F
6. I see the '%' is being there and that is causing problem.
7. I have set content-type to 'application/pdf' but that code is NOT reached. Probe fails at Binary Transformation.
?1? - Is this proper response? Will there be always '%' sign before PDF in ascii response??
?2? - How to sort the issue of illegal character at offset '0'.
?3? - How to send proper .pdf back to client so it gets displayed in the browser.
Any help is greatly appreciated.
Let me know, if more details are required.
This topic has been locked.
3 replies Latest Post - 2012-11-14T20:36:57Z by HermannSW
Pinned topic .pdf response processing
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-11-14T20:36:57Z at 2012-11-14T20:36:57Z by HermannSW
HermannSW 2700006U544325 PostsACCEPTED ANSWER
Re: .pdf response processing2012-11-14T08:57:44Z in response to SystemAdminHi,
I am not sure what you try to do here.
If you just want to display the PDF returned from backend in your browser, why not have a pass-thru response rule?
In addition, this posting may be interesting, if the returned PDF is not in clear:
Finally slide 18 from this WSTE webcast returns a ".gif" in the browser ("hear into" audio recording for details):
Just change content type to "application/pdf" for showing PDF files in a browser.
SystemAdmin 110000D4XK6772 PostsACCEPTED ANSWER
Re: .pdf response processing2012-11-14T14:09:43Z in response to HermannSWHi Hermann,
Thanks for reply.
Well, what I am doing is this -
We have common processing rule to process responses from backend.
The common rule wraps the response in XML tags, irrespective whether response was XML or Non-XML.
Then we check, whether child node of wrapper is XML or not. If not then we keep the XML wrappers otherwise we remove them.
It all works good. But now, we have requirement to pass .pdf back to browser.
I wanted to use same common processing rule - with some modifications to check for .pdf response and treat it differently.
Now the problem I face is , when response(.pdf) is received, I am not able to add wrapper.
It fails to parse in binary x-form action - with dp:parse error - illegal character at offset 0. I checked the content and there is '%' at offset 0.
HermannSW 2700006U544325 PostsACCEPTED ANSWER
Re: .pdf response processing2012-11-14T20:36:57Z in response to SystemAdminHi,
> Well, what I am doing is this -
> We have common processing rule to process responses from backend.
> The common rule wraps the response in XML tags, irrespective whether response was XML or Non-XML.
You cannot just "wrap" Non-XML data into a tag to make it XML.
The Non-XML data needs to consist of XML Characters only for doing so.
> Then we check, whether child node of wrapper is XML or not.
By your 1st comment you seem to use dp:parse() for that, which is fine.
A side effect of using dp:parse() is that you get an unmaskable error in the log, which may not be allowed in your production environment.
> If not then we keep the XML wrappers otherwise we remove them.
As said, adding XML wrappers only works for strings of XML Characters, not for arbitrary binary data.
> It all works good. But now, we have requirement to pass .pdf back to browser.
> I wanted to use same common processing rule - with some modifications to check for .pdf response and treat it differently.
> Now the problem I face is , when response(.pdf) is received, I am not able to add wrapper.
I mentioned the reasons above.
> It fails to parse in binary x-form action - with dp:parse error - illegal character at offset 0. I checked the content and there is '%' at offset 0.
What you could do is this:
1) take response as binaryNode
2) base64 encode that binaryNode by dp:binary-encode()
3) <xsl:if test="dp:parse(base64string,'base-64')/*"> (returns a node-set), return that (XML) and exit
4) if base64 encodes valid XML Character string, return wrapped string and exit
(you cannot use dp:decode(base64string,'base-64') for that
5) otherwise return binary data unchanged
For validating that base64string is utf-8 data without error abort, the only solution I know of is
calling "validate-base64()" from the stylesheet attached in this posting: