Layer7 API Management

  • Private Community

  • 1.  Debug failed post to restman for creating published service

    Posted Jun 13, 2017 03:40 AM

    Executing a get template towards my CA APIGW instance (https://localhost:9443/restman/1.0/services/template) yields:

     

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <l7:Item xmlns:l7="http://ns.l7tech.com/2010/04/gateway-management">
    <l7:Name>SERVICE Template</l7:Name>
    <l7:Type>SERVICE</l7:Type>
    <l7:TimeStamp>2017-06-13T07:30:22.487Z</l7:TimeStamp>
    <l7:Link rel="self" uri="https://d7a66e5db02e:9443/restman/1.0/services/template"/>
    <l7:Link rel="list" uri="https://d7a66e5db02e:9443/restman/1.0/services"/>
    <l7:Resource>
    <l7:Service>
    <l7:ServiceDetail folderId="FolderID">
    <l7:Name>My New Service</l7:Name>
    <l7:Enabled>false</l7:Enabled>
    </l7:ServiceDetail>
    <l7:Resources>
    <l7:ResourceSet tag="policy">
    <l7:Resource type="policy">Policy XML</l7:Resource>
    </l7:ResourceSet>
    </l7:Resources>
    </l7:Service>
    </l7:Resource>
    </l7:Item>

     

    From reading the template I expect to be able to create a new published service using post and the following body:

     

    <l7:Service>
    <l7:ServiceDetail folderId="0000000000000000ffffffffffffec76">
    <l7:Name>MyNewService</l7:Name>
    <l7:Enabled>false</l7:Enabled>
    </l7:ServiceDetail>
    <l7:Resources>
    <l7:ResourceSet tag="policy">
    <l7:Resource type="policy">Policy XML</l7:Resource>
    </l7:ResourceSet>
    </l7:Resources>
    </l7:Service>

     

    The POST to https://localhost:9443/restman/1.0/services however yields:

     

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
    <html>
    <head>
    <title>400 Bad Request</title>
    </head>
    <body>
    <h1>Bad Request</h1>
    <h3>The request sent by the client was syntactically incorrect.</h3>
    </body>
    </html>

     

    And there is no apparent way for me to debug what actually fails.

    I would expect to be able to trace the error in a log somewhere but can not find any documentation or examples of this.

     

    Can you please elaborate on how to work with this?



  • 2.  Re: Debug failed post to restman for creating published service
    Best Answer

    Broadcom Employee
    Posted Jun 13, 2017 11:52 AM

    To POST a service you will need to include some additional information such as the service name, the landing url, and the policy.

     

    This is a sample of the request for a POST service call that will publish  a basic hello world service. 

     

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <l7:Service xmlns:l7="http://ns.l7tech.com/2010/04/gateway-management">
    <l7:ServiceDetail folderId="0000000000000000ffffffffffffec76">
    <l7:Name>Hello World</l7:Name>
    <l7:Enabled>true</l7:Enabled>
    <l7:ServiceMappings>
    <l7:HttpMapping>
    <l7:UrlPattern>/hello_world/*</l7:UrlPattern>
    </l7:HttpMapping>
    </l7:ServiceMappings>
    </l7:ServiceDetail>
    <l7:Resources>
    <l7:ResourceSet tag="policy">
    <l7:Resource type="policy">&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
    &lt;wsp:Policy xmlns:L7p=&quot;http://www.layer7tech.com/ws/policy" xmlns:wsp=&quot;http://schemas.xmlsoap.org/ws/2002/12/policy">
    &lt;wsp:All wsp:Usage=&quot;Required&quot;&gt;
    &lt;L7p:HardcodedResponse&gt;
    &lt;L7p:Base64ResponseBody stringValue=&quot;PHJlc3BvbnNlPkhlbGxvIFdPcmxkITwvcmVzcG9uc2U+&quot;/&gt;
    &lt;/L7p:HardcodedResponse&gt;
    &lt;/wsp:All&gt;
    &lt;/wsp:Policy&gt;
    </l7:Resource>
    </l7:ResourceSet>
    </l7:Resources>
    </l7:Service>



  • 3.  Re: Debug failed post to restman for creating published service

    Posted Jun 26, 2017 04:05 AM

    Yes that call works, 

     

    How can I acquire a debug log of what actually fails in the call?



  • 4.  Re: Debug failed post to restman for creating published service

    Posted Aug 02, 2017 06:56 AM

    Hi,

    let me jump in to this discussion, as we have a similar issue here.

    It seems that above mentioned HTTP 400 error message is a default within the API-GW (same as a 204, if the incoming URI doesn't match with any configured policy). Additionally it seems to be not possible to debug such issues as such errors will be shown immediately before any debugging or logging of the policy could catch something.

    The reason why I'm asking this is, that the clients would expect a valid SOAP error message instead of this standard HTML-page. This would make troubleshooting much easier.

    If we send an non-valid SOAP request directly to the application Server (bypassing the API-GW) we see a meaningful SOAP error message.

    Therefor my question is, is there any chance to change this default behavior of the API-GW and if yes, where and how? Or is this really fix and the clients need to accept this?

    Thank you!

     

    Ciao Stefan



  • 5.  Re: Debug failed post to restman for creating published service

    Broadcom Employee
    Posted Aug 02, 2017 10:52 AM

    Hi Stefan,

     

    In this specific case the bad request was cause by the Service tag not having the l7 namespace defined in the message body. This error could have been seen in the audit using audit level of info. 

     

    In your case you said "It seems that above mentioned HTTP 400 error message is a default within the API-GW (same as a 204, if the incoming URI doesn't match with any configured policy)."

     

    The gateways default behavior is to return a HTTP 500 soap fault  if a service is not found.But I think what you are experiencing is the service is resolved and the SOAP message body is invalid it this case in the Service Properties if you disable the "Perform WS-Security processing for this service" check box this will allow the request to pass in to the service to be handled and you can return desired error response. 

     

    Thanks

    Barry



  • 6.  Re: Debug failed post to restman for creating published service

    Posted Aug 03, 2017 06:03 AM

    Hi Barry,

    The gateways default behavior is to return a HTTP 500 soap fault  if a service is not found.But I think what you are experiencing is the service is resolved and the SOAP message body is invalid it this case in the Service Properties if you disable the "Perform WS-Security processing for this service" check box this will allow the request to pass in to the service to be handled and you can return desired error response.

     

    This is exactly what I was looking for. After disabling this option we get the "correct" SOAP error-message from the server.

    Thank you!

     

    Ciao Stefan



  • 7.  Re: Debug failed post to restman for creating published service

    Posted Aug 02, 2017 12:27 PM

    Hi Barry,

    yes, let me explain our issue in more detail.

    We have deployed a SOAP service on the GW and if we send a valid (syntactically correct) request to it (e.g. via SoapUI) we get a valid response from the application. But if we modify this request (e.g. insert/remove a character in one of the tags, so the opening tag and the closing tag are not identical anymore, meaning the request is syntactically wrong), we get the mentioned HTTP-, instead of a SOAP-response.

    Ok, the content of the 400 error code also mentions this "The request sent by the client was syntactically incorrect.", but when handling with SOAP-requests you also would expect SOAP-responses. Otherwise you might be pointed in the wrong direction in case of troubleshooting. Maybe also the Client is not able to correctly handle HTTP-responses.

    If we send the same wrongly modified request directly to the application we see for example the following response:

    com.ctc.wstx.exc.WstxParsingException: Unexpected close tag &lt;/typ:Authentication>; expected &lt;/typ:Password>.  at [row,col {unknown-source}]: [6,26]

     

    That's why I'm wondering if this behavior can somehow be changed.

    I hope it's much clearer now.

    Thank you!

     

    Ciao Stefan



  • 8.  Re: Debug failed post to restman for creating published service

    Posted Nov 27, 2017 10:27 AM

    Hello Stefan/Barry

     

    I face the same error, I disabled the Perform WS-Security Processing for my service but still I get the Bad Request (HTML) error. any other reco?.

     

    Another variation I have when I still receive the error is when the content (no tags but real content) is coming with special characters example "&" data from the perspective of the caller is considered correct so is there any way I can accept this special characters and avoid the error?