Topic
3 replies Latest Post - ‏2012-11-14T20:36:57Z by HermannSW
SystemAdmin
SystemAdmin
6772 Posts
ACCEPTED ANSWER

Pinned topic .pdf response processing

‏2012-11-14T05:17:58Z |
Hi,

I am having trouble in processing .pdf response.

Scenario - webBrowser -> DP(MPGW) -> (Backend) RESTful WebService.
DP - XI50 Firmware Version 3.8.1.20

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"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:dp="http://www.datapower.com/extensions"
xmlns:dpconfig="http://www.datapower.com/param/config"
extension-element-prefixes="dp"
exclude-result-prefixes="dp dpconfig">
<dp:input-mapping href="XYZ.ffd" type="ffd"/>
<xsl:output method="xml"/>
<xsl:template match="/">
<xsl:copy-of select="."/>
</xsl:template>
</xsl:stylesheet>
++++++

XYZ.ffd is defined as
++++
<File name="input">
<Field name="wrapper"/>
</File>
++++
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.

Now,
?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.
Updated on 2012-11-14T20:36:57Z at 2012-11-14T20:36:57Z by HermannSW
  • HermannSW
    HermannSW
    4403 Posts
    ACCEPTED ANSWER

    Re: .pdf response processing

    ‏2012-11-14T08:57:44Z  in response to SystemAdmin
    Hi,

    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:
    https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14479355#14479355

    Finally slide 18 from this WSTE webcast returns a ".gif" in the browser ("hear into" audio recording for details):
    http://www-01.ibm.com/support/docview.wss?uid=swg27022979

    Just change content type to "application/pdf" for showing PDF files in a browser.

     
    Hermann<myXsltBlog/> <myXsltTweets/>
    • SystemAdmin
      SystemAdmin
      6772 Posts
      ACCEPTED ANSWER

      Re: .pdf response processing

      ‏2012-11-14T14:09:43Z  in response to HermannSW
      Hi 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
        HermannSW
        4403 Posts
        ACCEPTED ANSWER

        Re: .pdf response processing

        ‏2012-11-14T20:36:57Z  in response to SystemAdmin
        Hi,
        >
        > 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:
        https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14572518#14896430

         
        Hermann<myXsltBlog/> <myXsltTweets/>