ProxySG returns an HTTP 401 status code when using a "redirect-based" authentication mode
Last Updated May 13, 2017
You may intermittently experience an authentication popup window when your ProxySG is configured to use one of the redirect-based authentication modes -
A packet capture shows the ProxySG returning an HTTP 401 status code, instead of the expected redirect code (307 or 302.)
This normally occurs if the client sends a POST/PUT request that needs to be authenticated.
By default, authentication modes which redirect the browser use an HTTP 307 response code for Internet Explorer and an HTTP 302 response code for all other browsers. If an HTTP POST or PUT request requires authentication, a 307 redirect properly preserves the POST/PUT data, while a 302 redirect will convert the request to a GET and lose the POST/PUT data. The default behavior is to always preserve the POST/PUT data even at the cost of the authentication mode. To avoid losing the POST/PUT data, browsers which would use a 302 redirect are downgraded to a non-redirect authentication mode.
If the POST/PUT contains a multi-part mime type, Internet Explorer will not correctly preserve the data with a 307 redirect. The default behavior is to downgrade all multi-part POST/PUT requests to a non-redirect authentication mode. Downgrading the authentication mode preserves the data, but means that the user is not authenticated using the virtual URL. This can be an issue if credentials need to be secured by using an SSL virtual URL. This property can be used to override the default behavior and force the use of 307 redirects. This will ensure that the user is authenticated using the virtual URL.
There are two different popups which may occur: Most modern browsers support 307 redirects, but browsers other than Internet Explorer obey the RFC and display a pop-up asking the user if they want to repost/resubmit the data. This pop-up can be repeated numerous times during authentication.
Furthermore, when the proxy downgrades to a non-redirect authentication mode, it sends an HTTP 401 "Authentication required" response code. The web browser treats this as an authentication request from the actual web server, rather than the proxy. Since the web server is not in a trusted security zone, authentication credentials are not automatically submitted, and an authentication popup window appears.
The CPL code given below can be used to force 307 redirects for a given browser. This would help avoid the issue where the proxy returns a 401 status code and causes an authentication popup window.
Do not use this CPL code to force 307 redirects for Internet Explorer. Doing so will cause multi-part mime data in POST/PUT requests to be lost.
By using this CPL code, web browsers other than Internet Explorer may pop up a window asking for confirmation whether to resubmit the POST/PUT data. This is the behavior dictated by the RFC and cannot be worked around.
This example enables 307 redirects for Firefox. All other browsers will see the default behavior. Note that request.header.User-Agent condition is a regex and can be used to match any particular browser. This CPL code can be added to the proxy's local policy file. For information on how to add policy to the local policy file, please see000010101.
The solution above only applies to Firefox. See
KB3788 for the solution as it applies to versions of Internet Explorer that support this functionality.
Alternatively, you can bypass authentication and allow POST requests:
http.method=POST authenticate(no) allow
**Warning***In most cases disabling authentication for POST requests will not cause any problems but because of the fact that user/group authorization specific policy rules will NOT apply for POST requests when disabling authentication for such, there is a possibility that unexpected behavior may occur. For example: If there is a rule set in policy to forward only specific users/groups to a forwarding host such as another proxy or server, POST requests for such services will not be forwarded and this may disrupt service for those requests. In that case those destinations should be excluded from matching on this policy.
http.method=POST authenticate(no) allow
define condition Authenticated_POSTs_Required
; The policy above excludes the sites defined in the condition from matching on the rule in the layer (negated by "!" in the layer guard).
Imported Document ID: 000013054
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe
Thanks for your feedback. Let us know if you have additional comments below. (requires login)
Subscribed to the Article.
Unable to subscribe
Thanks for your additional feedback !!!
Enterprise Support Virtual Agent
Rate Me :
Tell us more:
Welcome! My name is Sami, the Enterprise Support Virtual Agent answering technical support questions.