Exceptions not behaving as expected with access_server(no) when response evaluation done

Products

• ProxySG Software - SGOS

Issue/Introduction

Policy that depends on response analysis such as "http.response.apparent_data_type=executable" can cause a result of, "DENIED: Request could not be handled" when used in combination with an "access_server(no)" action somewhere in the policy. 
 

<Proxy> 

MATCH:         category="File Storage/Sharing" exception(content_filter_denied) access_server(no) 

<Proxy> 

late:     http.response.apparent_data_type=executable

The content filter deny, and the late, ends up creating the "Request could not be handled"

GET <URL address>
authentication status='not_attempted' authorization status='not_attempted'
DENIED: Request could not be handled
  url.category: none@Policy;File Storage/Sharing@Blue Coat
    total categorization time: 1
    static categorization time: 1
server.response.code: 0
client.response.code: 403
application.name: none
application.operation: none
application.group: none
DSCP client outbound: 65
DSCP server outbound: 65

Cause

Non-forced exceptions/denials in policy are not finalized until there are no further allow/deny/exception rules in policy that could modify the decision.

In this case, there is a policy exception based on the http.response.apparent_data_type, which means that any non-forced exception/denial can't be finalized until the Proxy has seen the response.

If there is also an access_server(no) rule, which means the proxy can't contact the upstream server, the exception can't be finalized until the Proxy see the HTTP response, but the Proxy can't contact the server to get the response due to access_server(no) so the request is denied.

Due to access_server(no), the standard exception is not used but rather the reason shows up as "Request could not be handled", but it's really meaning that the Proxy can't continue to process the request due to the policy. It's still treated as a denial case, just with a different reason.

This is why the result changes if you test removing the http.response.apparent_data_type condition (or other conditions dependent on response analysis), because then the Proxy doesn't need to look at the response for any policy exception rules, and can finalize the exception before trying to contact the upstream server.

Resolution

In this case, if the desired result is to have the content_filter_denied exception displayed (or a different exception) the policy should be modified to use a force_exception as follows:

<Proxy>
category="File Storage/Sharing" force_exception(content_filter_denied) access_server(no)

force_exception means that this particular exception cannot be overridden by later rules. 
 
Using force_exception() would make the exception commit right away, which would make that the termination reason in the policy decision.