从https重定向到http？

Question

奇怪的问题在这里。我使用FullCalendar向我的服务器上的端点发起ajax请求。端点是：

SELECT 'Edit Set' AS 'Edit Set', 'Employee No.' AS 'Employee No.' FROM LatestEligible UNION ALL SELECT DISTINCT NULL AS 'Edit Set', d.EmployeeID AS 'Employee No.' FROM LatestEligible d INNER JOIN Employee e ON d.EmployeeID = e.EmployeeID INNER JOIN Inv_DataReimbursement dr ON d.EmployeeID = dr.EmployeeID AND d.LatestBillVerified = dr.DateBillVerified WHERE (dr.MonthlyServiceEligible = 'true' OR (dr.MonthlyServiceEligible = 'false' AND e.DateEnd IS NOT NULL AND e.DateEnd > @NextPayrollDate)) AND dr.ActualAmount > 0

请注意，它是明确的https。但是，当我发起一个请求（即Fullcalendar发起一个请求）时，我得到301并重定向到非https端点：

https://my_website/events/?start=2019-03-31&end=2019-05-12&_=1555698739056

失败，因为页面是通过https加载的。

端点工作正常-当我将其加载到浏览器中时，得到了预期的json输出（通过https）。此页面上发生了其他ajax请求，这些请求可以正常运行，并且我使用Fullcalendar在此站点上的其他地方（到另一个端点）成功地执行了完全相同的操作。只是这种情况下表现异常。

可能值得注意的是，它位于nginx反向代理/负载均衡器后面的docker容器中；站点配置非常简单：

http://my_website/events?start=2019-03-31&end=2019-05-12&_=1555698739056

请求的nginx日志如下：

  

134.124.11.91--[19 / Apr / 2019：13：49：49 -0500]“ GET / events /？start = 2019-04-28＆end = 2019-06-09＆_ = 1555699678658 HTTP / 1.1” 301 0 “ https://my_website”“ Mozilla / 5.0（Windows NT 10.0; Win64; x64）AppleWebKit / 537.36（KHTML，例如Gecko）Chrome / 73.0.3683.103 Safari / 537.36”

有人看到我所缺少的东西会导致这种奇怪的301重定向到非https端点吗？

Answer 1

问题

这似乎是因为您没有使用规范的URL，而您的后端正在通过这些301重定向来强制执行此类URL，而实际上却不知道规范的地址方案。

---

解决方案

• 最佳解决方案是将您的 前端 代码修复为始终使用规范URL。例如，在您提供的示例中，API端点中是否存在斜杠。

• 您可能应该配置您的 后端 ，以正确了解它正在通过https访问，例如，添加如下内容在您的nginx中所有其他proto_set_header指令旁边，该指令终止https并将流量传递到后端：

  proto_set_header    X-Forwarded-Proto   $scheme;
  

---

其他想法

• 另一种解决方案是配置http://nginx.org/r/proxy_redirect以正确识别后端返回的本地Location标头，并根据需要即时转换它们；但是，根据您的情况，前两种选择可能是更好的方法。

Answer 2

我不太确定，因为您的屏幕截图有些冲突，但是可以：

在您的检查器屏幕截图中，我们看到一个对https的请求（已取消）和一个对http的请求（由于混合协议而被阻止）。提示位于已取消的提示中，被取消意味着那里没有重定向，但浏览器认为不再需要该请求。以前有几个问题也有类似的问题，请参见here和here两个示例。

请求被取消的原因之一是，您用来更改FullCalendar日期的按钮/输入/链接不仅是在执行ajax请求，而且还在执行第二个http请求（由于包装形式，href，等等）。您尚未包括FullCalendar实现的html和JavaScript，所以我不确定是否要知道这一点，但是请检查输入元素周围是否没有表格，或者是否编写了自己的事件处理程序，请执行以下操作。 >

function(e){
  e.preventdefault(); 

  .... // your date switching code here 

  return false;
}

如果您使用具有onclick属性的链接，请确保在末尾添加...(yourcode);return false;。

重要提示：如果我的理论是正确的，则意味着您日志中的行实际上与检查器中看到的内容并不完全相同，实际上是从HTTP重定向到HTTPS的重定向，并非相反。这很难看，因为nginx默认不将请求协议包括在日志中。