Layer7 API Management

I have a Route via HTTPS assertion which returns a 200 status code, however the assertion fails (600) with the audit log message "Error reading response" (code 4006). Can't see to find much information on this code.... Does anyone have any hints how I might be able to debug this further?

Hi there

I would suggest to search in the ssg log for "ServerHttpRoutingAssertion: 4006: Error reading response" records.

Usually the entry record below the one containing the error code , should show a Java exception which gives you a hint of what the problem is.

Regards

Hi Cristiano,

This is what I'm seeing in the ssg log; unfortunately it doesn't give enough information to debug further. Note I have an additional log sink setup set to track at the "finest" level.

Cheers

Ash

Hello ashk ,

ssg log is not the same as audit log, you need to find it on gateway server,

/opt/SecureSpan/Gateway/node/default/var/logs/ssg_0_0.log

Regards,

Mark

Mark,

That screenshot was from the log viewer in policy manager; specifically, ssg_0_0.log. 

I've updated the log.levels config item to include "com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion.level = ALL" and this is showing a lot more information in my log sink, but still there are no exception errors, or otherwise, shown in any of the logs.

Ashk

I believe what Mark was trying to point out is that you should search the error records in the /opt/SecureSpan/Gateway/node/default/var/logs/ssg_0_0.log "file" by connecting to the Gateway via SSH. Policy Manager Log Viewer may not show the fully story.

Ashk, if you prefer, feel free to open a case with Support. I'll be more than happy to review the logs live with you.

Thanks, it's still not showing enough info - what I'm seeing via SSH and on the gateway via the log viewer is the same:

2017-07-06T14:25:10.314+1000 FINEST 1495 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: Skipping security header processing, message not XML
2017-07-06T14:25:10.329+1000 FINE 1495 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: HTTP request header added [User-Agent]=[Layer7-SecureSpan-Gateway/v9.2.00-b6904]
2017-07-06T14:25:10.330+1000 FINE 1495 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: HTTP request header added [Content-Type]=[application/x-www-form-urlencoded]
2017-07-06T14:25:12.194+1000 FINE 1495 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: HTTP response header [Content-Type]=[application/json]
2017-07-06T14:25:12.194+1000 FINE 1495 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: HTTP response header [X-Global-Transaction-ID]=[197267165]
2017-07-06T14:25:12.194+1000 FINE 1495 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: HTTP response header [Access-Control-Allow-Origin]=[*]
2017-07-06T14:25:12.194+1000 FINE 1495 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: HTTP response header [Access-Control-Allow-Methods]=[POST]
2017-07-06T14:25:12.195+1000 FINE 1495 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: HTTP response header [Content-Type]=[application/json]
2017-07-06T14:25:12.195+1000 FINE 1495 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: HTTP response header [Content-Length]=[387]
2017-07-06T14:25:12.195+1000 FINE 1495 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: HTTP response header [Date]=[Thu, 06 Jul 2017 04:25:12 GMT]
2017-07-06T14:25:12.195+1000 FINE 1495 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: HTTP response header [Connection]=[close]
2017-07-06T14:25:12.202+1000 INFO 1495 com.l7tech.server.message: Processing request for service: Get Key [/localdev/getkey/]
2017-07-06T14:25:12.205+1000 WARNING 1495 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: 4006: Error reading response
2017-07-06T14:25:12.205+1000 INFO 1495 com.l7tech.server.MessageProcessor: 3017: Policy evaluation for service Get Key [390854b29666f909b77d790690b5baa6] resulted in status 600 (Assertion Falsified)
2017-07-06T14:25:12.206+1000 WARNING 1495 com.l7tech.server.message: Message was not processed: Assertion Falsified (600)

Hello ashk ,

Since the log cannot provide enough info, it maybe better to open a support ticket to investigate further.

Regards,

Mark

Ashk,

Usually this 4006 seems to be a data type mismatch. I dont know if a ticket was open. The 4006 is seen on a few cases with MIME messages and not having the correct formatting tags. Is the Data type set correct? application/json. 

It would probably be worth while as the other mentioned to open a ticket and if you have your sample policy and post data to upload these.

Thanks,Charlie.

Thanks Charles, this sounds like it could be the culprit. The request message is of type application/x-www-form-urlencoded, and the response is application/json - does this sound like it'd cause an issue, and how would I work around this? The protected API requires the POST message with form variables for it's own OAuth authentication.

We have a CA consultant on site this week, but would appreciate if anyone has any tips on how to achieve this 

After further testing, we've found in the gateway log that the response message is returned to the gateway, but for whatever reason, it can't read it. The response headers include a "Connection: Close" header which appears to be introduced by our upstream proxy - would this cause the gateway to stop processing the response message?

Ashley,

The connection:close used in the request will tell the server that the client does not want to maintain the connection after the response and when it is in the response that the server will not keep alive the connection. It tends not to have any affect on receiving the message as long as all the packets are received. Being that it is occurring between the back-end and the Gateway, the entire response message may not have been received prior to the last part of the response.

As for the content-type, switching between inbound content-type and response content-type is not an issue as we can covert it back and forth.

I would suggest you try to remove the proxy to see if it corrects the problem.

Sincerely,

Stephen Hughes

Director, CA Support

We are working on the support ticket, it seems it's due to the duplicate Content-type in the response message.

As above, the issue ended up being the content type being included in the HTTP header response twice from the downstream API. Unfortunately the Gateway isn't able to deal with this and just rejects it. Very obscure issue.