<403>禁用https：// URL，<302>使用http：// URL暂时移动

Our web authentication platform faced an unexpected behavior couple days ago when a user was unable to connect to our authentication servers, which is actually a method that POSTs data to our URL at https://xxxxxxxx.com/authentication/authorize.php. We were unsure what the problem was - our servers? The client they were using? Their firewalls?

This is the method we used through the experimentation below:

    HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create(url);
    webRequest.CookieContainer = new CookieContainer();
    webRequest.AllowAutoRedirect = false; // false so we don't get redirected

    using (HttpWebResponse webResponse = (HttpWebResponse)webRequest.GetResponse())
    {
        headers.Add("Status Code: " + (int)webResponse.StatusCode);
        headers.Add("Status Desc: " + webResponse.StatusDescription);
        foreach (string key in webResponse.Headers.Keys)
        {
            if (!key.ToString().Equals("Location"))
            {
                var value = webResponse.Headers[key];
                headers.Add(key + ": " + value);
            }
        }
    }

We had him send over a header report:

It appears we were were 4XX tier status code errors from this user.

Upon Googling, we found this article which instructs you to change the .htacess files. Specifically, it's an issue where your website host may be implementing filtering which creates a mod_security error.

We put this code snippet into our .htacess:

<IfModule mod_security.c>
 SecFilterEngine Off
 SecFilterScanPOST Off
</IfModule>

We ask the user to run our headers script again, and this was returned:

The https:// URL still returned a <403> Forbidden error, however, the http:// domain (non-encrypted one) finally gave us a voice. Note, the desired status code is a 302 Found, as any one that tries to navigate into that URL should be redirected to our host domain. It seems in this issue, we got a 302 Moved Temporarily.

From our experimentation, it looks like changing .htaccess did indeed allow us to make some progress, but not using the https:// protocol is an issue. We have contacted our server hosts asking for some insight as to why this is happening (such as -- do you guys implement filtering?), and we are currently waiting for a reply.

My question is -- what is going on? Have you encountered this issue before?