AnsweredAssumed Answered

Debug failed post to restman for creating published service

Question asked by dozeone on Jun 13, 2017
Latest reply on Nov 27, 2017 by henriquez.h

Like • Show 0 Likes0
Comment • 7

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?

steba03

Jun 13, 2017 3:52 PM

Correct Answer

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"><?xml version="1.0" encoding="UTF-8"?>
<wsp:Policy xmlns:L7p="http://www.layer7tech.com/ws/policy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy">
<wsp:All wsp:Usage="Required">
<L7p:HardcodedResponse>
<L7p:Base64ResponseBody stringValue="PHJlc3BvbnNlPkhlbGxvIFdPcmxkITwvcmVzcG9uc2U+"/>
</L7p:HardcodedResponse>
</wsp:All>
</wsp:Policy>
</l7:Resource>
</l7:ResourceSet>
</l7:Resources>
</l7:Service>

See the reply in context

No one else had this question

Outcomes

steba03

Jun 13, 2017 3:52 PM

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.

2 people found this helpful

Actions

dozeone @ steba03 on Jun 26, 2017 8:04 AM

Yes that call works,

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

Actions

StefanKlotz Aug 2, 2017 10:55 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

Actions

steba03

@ StefanKlotz on Aug 2, 2017 3:06 PM

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

1 person found this helpful

Actions

StefanKlotz @ steba03 on Aug 3, 2017 10:02 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

Actions

StefanKlotz Aug 2, 2017 4: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 </typ:Authentication>; expected </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

Actions

henriquez.h @ StefanKlotz on Nov 27, 2017 3:26 PM

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?

Actions

7 Replies

steba03 Jun 13, 2017 3:52 PM
Unmark Correct
Correct Answer
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"><?xml version="1.0" encoding="UTF-8"?>
<wsp:Policy xmlns:L7p="http://www.layer7tech.com/ws/policy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy">
<wsp:All wsp:Usage="Required">
<L7p:HardcodedResponse>
<L7p:Base64ResponseBody stringValue="PHJlc3BvbnNlPkhlbGxvIFdPcmxkITwvcmVzcG9uc2U+"/>
</L7p:HardcodedResponse>
</wsp:All>
</wsp:Policy>
</l7:Resource>
</l7:ResourceSet>
</l7:Resources>
</l7:Service>
2 people found this helpful
Like • Show 2 Likes2
Actions
- dozeone @ steba03 on Jun 26, 2017 8:04 AM
  Mark Correct
  Correct Answer
  Yes that call works,
  
  How can I acquire a debug log of what actually fails in the call?
  Like • Show 0 Likes0
  Actions
StefanKlotz Aug 2, 2017 10:55 AM
Mark Correct
Correct Answer
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
Like • Show 0 Likes0
Actions
- steba03 @ StefanKlotz on Aug 2, 2017 3:06 PM
  Mark Correct
  Correct Answer
  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
  1 person found this helpful
  Like • Show 1 Like1
  Actions
  - StefanKlotz @ steba03 on Aug 3, 2017 10:02 AM
    Mark Correct
    Correct Answer
    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
    Like • Show 0 Likes0
    Actions
StefanKlotz Aug 2, 2017 4:27 PM
Mark Correct
Correct Answer
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 </typ:Authentication>; expected </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
Like • Show 0 Likes0
Actions
- henriquez.h @ StefanKlotz on Nov 27, 2017 3:26 PM
  Mark Correct
  Correct Answer
  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?
  Like • Show 0 Likes0
  Actions

Debug failed post to restman for creating published service

Outcomes

Related Content

Recommended Content