Topic
  • 3 replies
  • Latest Post - ‏2013-02-14T09:59:56Z by HermannSW
SystemAdmin
SystemAdmin
6772 Posts

Pinned topic Is this a Bug in DP?

‏2013-02-13T18:53:20Z |
XI52 Firmware 5.0.0.3

We have an XMLFW which takes a JSON message in via HTTP and spits it straight out to a back end server via HTTPS. The processing policy is this:

JSON message HTTP in => Match All => Results => Static HTTPS Backend JSON message

If the probe is OFF, this doesn't work. If the probe is ON, it works.

So, we changed the policy to pass through the request. Same exact issue. So, we changed the policy to this:

JSON message HTTP in => Match All => Identity XFORM (output junk) => (input INPUT) Results => Static HTTPS Backend JSON message

This works whether the probe is on or off, and even if the request message type is JSON or passthrough.

Any ideas?
Updated on 2013-02-14T09:59:56Z at 2013-02-14T09:59:56Z by HermannSW
  • bruneves
    bruneves
    42 Posts

    Re: Is this a Bug in DP?

    ‏2013-02-13T21:28:47Z  
    Joe,

    Not sure if that is your case, but I wanted to share the following...

    I faced a similar issue in the past when I was doing some tests related to streaming messages. With probe set to on, it worked fine, probe set to off, blah!

    For my case, turning the probe on was actually disabling streaming and making it work, probe off would try to stream the message, but as there was something else wrong in my code/configuration, it would fail.

    IBM recently released a technote related to that. They recommend removing the Streaming Rule from the "Compile Options Policy" attached to the XML Manager.

    http://www-01.ibm.com/support/docview.wss?uid=swg21606887
  • SystemAdmin
    SystemAdmin
    6772 Posts

    Re: Is this a Bug in DP?

    ‏2013-02-13T21:55:35Z  
    • bruneves
    • ‏2013-02-13T21:28:47Z
    Joe,

    Not sure if that is your case, but I wanted to share the following...

    I faced a similar issue in the past when I was doing some tests related to streaming messages. With probe set to on, it worked fine, probe set to off, blah!

    For my case, turning the probe on was actually disabling streaming and making it work, probe off would try to stream the message, but as there was something else wrong in my code/configuration, it would fail.

    IBM recently released a technote related to that. They recommend removing the Streaming Rule from the "Compile Options Policy" attached to the XML Manager.

    http://www-01.ibm.com/support/docview.wss?uid=swg21606887
    Unfortunately, that's not the problem here. This one is using the default XMLManager and it doesn't have a compile options policy attached.

    It seems, for us, by putting on the junk identity transform, it forces it into some kind of state that enables it to handle the message correctly.
  • HermannSW
    HermannSW
    4741 Posts

    Re: Is this a Bug in DP?

    ‏2013-02-14T09:59:56Z  
    Unfortunately, that's not the problem here. This one is using the default XMLManager and it doesn't have a compile options policy attached.

    It seems, for us, by putting on the junk identity transform, it forces it into some kind of state that enables it to handle the message correctly.
    Hi,

    please find attached the scenario you describe (5.0.0.3 export).
    For me it works without problems, see below.

    Because the export does not contain crypto certs and keys, you will need to bring up cyrpto profiles "client" and "server" first.

    HTTP XML FW service "ptJSON"
    • listens on port 2054
    • has "Pass through" request type
    • uses "default" policy (any policy is fine in case of pass-thru)
    • goes to https://127.0.0.1:40001 HTTPS backend simulation
    • uses Forward Crypto Profile "client"
    • has pass-thru response type

    HTTPS XML FW "ptlbssl"
    • listens on port 40001
    • is loopback XML FW
    • uses "default" policy (any policy is fine in case of pass-thru)
    • uses Backward Crypto Profile "server"
    No difference in in what gets send and received from backend:
    
    $ curl --data-binary @germany.json http:
    //nightcrawler:2054 -s | diff germany.json - $ $ curl --data-binary @germany.json http:
    //nightcrawler:2054 -s  
    {
    "identifier":
    "abbreviation", 
    "label": 
    "label", 
    "items": [ 
    {
    "name":
    "Baden-Württemberg", 
    "label":
    "Baden-Württemberg",
    "abbreviation":
    "BW"
    }, 
    {
    "name":
    "Bavaria", 
    "label":
    "Bayern",
    "abbreviation":
    "BY"
    }, 
    {
    "name":
    "Berlin", 
    "label":
    "Berlin",
    "abbreviation":
    "BE"
    }, 
    {
    "name":
    "Brandenburg", 
    "label":
    "Brandenburg",
    "abbreviation":
    "BB"
    }, 
    {
    "name":
    "Bremen", 
    "label":
    "Bremen",
    "abbreviation":
    "HB"
    }, 
    {
    "name":
    "Hamburg", 
    "label":
    "Hamburg",
    "abbreviation":
    "HH"
    }, 
    {
    "name":
    "Hesse", 
    "label":
    "Hessen",
    "abbreviation":
    "HE"
    }, 
    {
    "name":
    "Mecklenburg-Vorpommern", 
    "label":
    "Mecklenburg-Vorpommern",
    "abbreviation":
    "MV"
    }, 
    {
    "name":
    "Lower Saxony", 
    "label":
    "Niedersachsen",
    "abbreviation":
    "NI"
    }, 
    {
    "name":
    "North Rhine-Westphalia", 
    "label":
    "Nordrhein-Westfalen",
    "abbreviation":
    "NW"
    }, 
    {
    "name":
    "Rhineland-Palatinate", 
    "label":
    "Rheinland-Pfalz",
    "abbreviation":
    "RP"
    }, 
    {
    "name":
    "Saarland", 
    "label":
    "Saarland",
    "abbreviation":
    "SL"
    }, 
    {
    "name":
    "Saxony", 
    "label":
    "Sachsen",
    "abbreviation":
    "SN"
    }, 
    {
    "name":
    "Saxony-Anhalt", 
    "label":
    "Sachsen-Anhalt",
    "abbreviation":
    "ST"
    }, 
    {
    "name":
    "Schleswig-Holstein", 
    "label":
    "Schleswig-Holstein",
    "abbreviation":
    "SH"
    }, 
    {
    "name":
    "Thuringia", 
    "label":
    "Thüringen",
    "abbreviation":
    "TH"
    }, ]
    } $
    


     
    Hermann<myXsltBlog/> <myXsltTweets/>