我不知道你的主机是谁，但我只是碰到了对的 AppHarbor 并在他们的知识基础发现了这个：

  

如果您使用的是内置RequireHttpsAttribute以确保
  控制器动作总是使用HTTPS，你将体验到一个重定向
  循环。其原因是，SSL终止于负载均衡水平
  而RequireHttps不承认的X转发，原标题是
  使用以指示该请求已被使​​用HTTPS制成。你应该
  因此，使用自定义RequireHttps为此属性。

块引用>

他们还提供了Github上这里，一个例子的解决方案，我会复制下面为了方便：

 使用系统;
使用System.Web.Mvc;
使用RequireHttpsAttributeBase = System.Web.Mvc.RequireHttpsAttribute;命名空间AppHarbor.Web
{
    [AttributeUsage（
        AttributeTargets.Class | AttributeTargets.Method，
        继承= TRUE，
        的AllowMultiple = FALSE）]
    公共类RequireHttpsAttribute：RequireHttpsAttributeBase
    {
        公共覆盖无效OnAuthorization（AuthorizationContext filterContext）
        {
            如果（filterContext == NULL）
            {
                抛出新的ArgumentNullException（filterContext）;
            }            如果（filterContext.HttpContext.Request.IsSecureConnection）
            {
                返回;
            }            如果（string.Equals（filterContext.HttpContext.Request.Headers [X  - 转发，原]，
                https开头，
                StringComparison.InvariantCultureIgnoreCase））
            {
                返回;
            }            如果（filterContext.HttpContext.Request.IsLocal）
            {
                返回;
            }            HandleNonHttpsRequest（filterContext）;
        }
    }
}
 

我不知道这是否会解决你的问题。但也许，即使你不使用AppHarbor的根本原因可能是你的一样，在这种情况下，上述似乎值得一试。

I'm trying to build a web application that uses an SSL connection. So I did some research and found out that I could use the RequireHttpsAttribute class to achieve what I needed. Thing is that when I use it, the execution of the application results in an 310 error(too many redirections). I even built a custom class to handle the switch from http to https. But that too results in an error.

My Class to handle te protocol switch:

Public Class RequireSSLAttribute
    Inherits ActionFilterAttribute

    Public Property IsRequired() As Boolean

    Public Overrides Sub OnActionExecuting(filterContext As ActionExecutingContext)
        If Me.IsRequired AndAlso filterContext.HttpContext.Request.Url.Scheme <> "https" Then
            filterContext.HttpContext.Response.Redirect(filterContext.HttpContext.Request.Url.OriginalString.Replace("http:", "https:").Remove(filterContext.HttpContext.Request.Url.OriginalString.LastIndexOf(":") + 1), True)
            filterContext.Result = New HttpUnauthorizedResult
        End If
    End Sub

    Public Sub New()
        IsRequired = True
    End Sub
End Class

I don't know who your host is, but I just ran into a similar problem on AppHarbor and discovered this in their knowledge base:

If you're using the built-in RequireHttpsAttribute to ensure that a controller action always uses HTTPS you will experience a redirect loop. The reason is that SSL is terminated at the load balancer level and RequireHttps doesn't recognize the X-Forwarded-Proto header it uses to indicate that the request was made using HTTPS. You should therefore use a custom RequireHttps attribute for this purpose.

They have also provided an example solution on Github here, which I will copy below for convenience:

using System;
using System.Web.Mvc;
using RequireHttpsAttributeBase = System.Web.Mvc.RequireHttpsAttribute;

namespace AppHarbor.Web
{
    [AttributeUsage(
        AttributeTargets.Class | AttributeTargets.Method,
        Inherited = true,
        AllowMultiple = false)]
    public class RequireHttpsAttribute : RequireHttpsAttributeBase
    {
        public override void OnAuthorization(AuthorizationContext filterContext)
        {
            if (filterContext == null)
            {
                throw new ArgumentNullException("filterContext");
            }

            if (filterContext.HttpContext.Request.IsSecureConnection)
            {
                return;
            }

            if (string.Equals(filterContext.HttpContext.Request.Headers["X-Forwarded-Proto"],
                "https",
                StringComparison.InvariantCultureIgnoreCase))
            {
                return;
            }

            if (filterContext.HttpContext.Request.IsLocal)
            {
                return;
            }

            HandleNonHttpsRequest(filterContext);
        }
    }
}

I'm not sure if this will solve your problem; but perhaps even if you aren't using AppHarbor the root cause may be the same for you, in which case the above seems worth a shot.