stackoverflow.com现在是
https://。我已经在博客文章中写到了很多内容。接下来是聊天，然后是
https-仅cookie。我们将不断完善HSTS max-age指令。我将在部署新位时继续更新此帖子。更新2017-03-16
我们从
meta.*.stackexchange.com重定向了所有子元流量到*.meta.stackexchange.com，并且现在强制使用HTTPS。我们还重新烘焙了网络内部的链接（注释除外），以指向新的域和协议。我们将在最后发表评论。我们知道HTTPS到处用户在这里重定向过多，不幸的是问题出在他们的规则集上。我已经提交了一份PR，以在这里解决此问题：EFForg / https-everywhere /＃9110
我们正在暂停进一步的迁移，同时我们观察到Google在下周左右如何处理超级用户之类的网站。我将于3月27日放假，我们计划部署
Content-Security-Policy-Report-Only标头进行报告，然后在所有主要网站上进行完整的问答集部署。初始帖子
这是一个提示，并要求帮助。相关信息：来自我们测试站点的原始文章Meta Stack Overflow。整个网络的HTTPS早就该发布了，但是我们一直在幕后努力。当我们在详细介绍旅程的任何地方打开它时，都会期待一个相当大的博客文章。
关于HTTPS的一些挥之不去的问题，直到我们付诸实践后，我们才能确定。其中之一是Google网站站长的迁移。仍然（我们难以置信）将HTTP和HTTPS视为不同的属性。我不知道为什么。而且“地址更改”工具也不支持这种移动：
注意：该工具当前不支持以下站点移动：子域名更改，协议更改（从HTTP到HTTPS）或仅路径更改。
因此，在迁移到HTTPS期间，我们必须为每个站点创建属性集。有趣！
鉴于以上所述，我们需要了解所有这些在实际负载下的实际工作方式：我们从meta.stackoverflow.com和meta.stackexchange.com开始。
这里（每个站点）正在发生的事情是一个顺序：
已完成的基础架构：
用于本地终止的快速CDN /代理（快速）
证书（包括用于桥接HTTP / 1.1和HTTP / 2的IP池支持）
记录
done获得适当的第三方支持：
所有每个站点脚本都已放到我们的CDN上，并可以安全地提供
广告提供商到HTTPS
>
完成修复大量假设
http://在100万个地方的代码。done防止用户嵌入新的
http://内容（例如，强制使用HTTPS图像）。done清理所有
http://的现有用户内容（如果可能，请https://，如果我们不能安全地嵌入它，则转换为链接）。 s https://。完成将规范化的URL移至
https://。完成301流量全部访问
https://。完成（子元数据）从
meta.*.stackexchange.com到*.meta.stackexchange.com。将所有Q＆A流量强制到
https://（并设置一个仅使用https的cookie）迁移所有现有会话以保护会话（这将需要一些时间才能运行）。浏览器根本不会通过
http://来访问问答网站。这是用于问答。 51区，聊天室和stackexchange.com（主站点）有单独的关注点和代码集，我们将在进行问答后予以解决。该列表也不一定按顺序排列。在测试＃6时，我和Samo将同时在＃11上工作。但是，我们必须在整个网络中完成所有这些工作，现在我们就开始该过程。
meta.stackoverflow.com是我们本周的测试场地。虽然我们仍在等待Google的分析赶上来，以便我们评估影响，但我们已经准备好在更多站点上进行访问。这是我们的大致列表：完成
meta.stackoverflow.com 完成
meta.stackexchange.com 完成
security.stackexchange.com（为什么？该社区具备测试HTTPS问题并提供反馈的功能）完成
meta.security.stackexchange.com（移至security.meta.stackexchange.com）stackoverflow.com 完成问答网站的主要站点除了stackoverflow.com（例如
*.stackexchange.com，superuser.com）完成堆栈溢出本地子元数据（例如
meta.ja.stackoverflow.com移至ja.meta.stackoverflow.com）完成问答网络子元站点（例如
meta.*.stackexchange.com）完成
stackexchange.com（顶级非问答域）完成
area51.stackexchange.com （需要计划）
chat.stackoverflow.com，chat.stackexchange.com和chat.meta.stackexchange.com 我们希望您的帮助仅报告
https://上内容不安全的任何问题或您看到的任何其他异常情况。我们将尝试尽快解决它们。既然我们被问到很多，是的-我将在本文结束时写一篇详尽的博客文章，介绍我们一路走来遇到的一切。#1 楼
状态完成的，每次我访问https://meta.stackoverflow.com时，都会向我显示
“此页面正试图从未经身份验证的页面加载脚本”。
是否存在问题这里？连接到不安全的WebSocket端点
https://meta.stackoverflow.com/questions/345125/suggested-edit-queue-is-full?cb=1。该请求已被阻止；此端点必须可以通过WSS使用。UPDATE
它在https://meta.stackexchange.com上也具有相同的功能：
评论
FWIW，在Firefox上使用HTTPS Everywhere并加载确切的问题URL，我发现Firefox无法在wss：//qa.sockets.stackexchange.com/建立与服务器的连接。在Firebug控制台中。
–用户
17 Mar 8 '17 at 17:42
显然，** www。** meta.stackoverflow.com不会为我加载，而是删除了www。使它加载得很好
–user41805
17 Mar 8 '17 at 17:59
@MichaelKjörlingFWIW是什么意思？
–苏拉杰（Suraj Jain）
17 Mar 8 '17 at 18:46
@SurajJain FWIW =值得的。
–用户
17 Mar 8 '17 at 18:52
我不确定这是一个问题，因为该站点从未存在。我们的网域都不在www。 （如果您尝试二级域名，我们会从中重定向）。基本上：这并不是什么新鲜事物，该域甚至不在DNS中。
–尼克·克拉弗♦
17年8月8日在19:24
@NickCraver您是什么意思，没有域名在www上？
–苏拉杰（Suraj Jain）
17 Mar 8 '17 at 21:52
@NickCraver实际上，正如您在图像中看到的那样，当在非www上访问时，它会给出问题。
–苏拉杰（Suraj Jain）
17 Mar 8 '17 at 21:55
@SurajJain我的意思是我们不使用www。前缀，有时我们会将它们从重定向到方便，仅此而已。我不确定为什么您的安全websocket（wss：//）被阻止或中断（单独的问题），但是我为网络的全局移动准备了不安全的websocket（ws：//）。您是否再看到问题了？
–尼克·克拉弗♦
17 Mar 9 '17 at 0:41
@NickCraver真正发生了什么？我再也看不到了，你做了什么？
–苏拉杰（Suraj Jain）
17 Mar 9 '17 at 16:13
@NickCraver如果在图像中看到它是不安全的套接字而不是wss，则表示在站点上不安全的套接字被阻止了
–苏拉杰（Suraj Jain）
17年3月9日在16:16
@NickCravermeta.stackoverflow.com/questions/345125/…上的页面已通过HTTPS加载，但试图连接到不安全的WebSocket端点ws：//qa.sockets.stackexchange.com/。该请求已被阻止；该端点必须在WSS上可用。在我回答之后，您禁用了不安全的websocket？
–苏拉杰（Suraj Jain）
17年9月9日在16:23
@SurajJain不安全套接字现在已在整个网络上被禁用，是的。由于它们只会在不久的将来导致混合内容警告。它们仅是一种后备，而将来却是无效的。
–尼克·克拉弗♦
17 Mar 10 '17 at 23:41
@NickCraver只是一个问题，我不明白您的意思是它们只是一个后备，而是一个无效的前进。
–苏拉杰（Suraj Jain）
17 Mar 11 '17 at 17:17
@SurajJain“仅回退”表示仅在由于某种原因而无法使用wss：//时才使用ws：//。现在，按设计，ws：//根本不再起作用，如果无法使用ws：//，即使尝试使用ws：//也没有意义。
–hvd
17年3月11日18:00
@Avamander HSTS：是的，搬家之后。 HPKP：也许，那里有很多工作（带有子域）非常棘手。还有更多的思考。
–尼克·克拉弗♦
17 Mar 16 '17 at 0:28
#2 楼
HTTPS Everywhere扩展可能会引起麻烦
…当HTTPS被强制到处（步骤10）时。目前，用于Stack Exchange的规则集包含对所有深两个级别的子域（例如
*.meta.stackexchange.com）的强制降级到HTTP。 meta.stackexchange.com降级为HTTP。）这是有问题的规则：
<!-- https links from other pages to these will cause MCB for important elements, hence the downgrades -->
<rule from="^https://([\w.-]+)\.([\w-]+)\.stackexchange\.com/"
to="http://..stackexchange.com/" downgrade="1" />
某人可能需要发送带有修复的请求请求（如果我有时间的话，我可能会自己做），这可能是个好主意在启动步骤10之前，要等到固定规则出现在HTTPS Everywhere中。
编辑：我对HTTPS Everywhere源进行了一些挖掘，它确实包含一些检测重定向循环的逻辑；因此，即使其中包含降级规则，它最终还是应该放弃并允许HTTPS站点加载。
评论
这是导致security.meta.stackexchange.com重定向您太多次的原因了。尝试在Chrome中查看网站时出现错误消息？
–科多斯·约翰逊（Kodos Johnson）
17年3月14日在19:09
我在Firefox上安装了HTTPS Everywhere，起初确实注意到了此错误，但现在不再注意，它可以为我正确地提供HTTPS版本。
– SEJPM
17 Mar 14 '17 at 20:01
当我们进行网络更改时，我将向扩展名提交PR。
–尼克·克拉弗♦
17 Mar 14 '17 at 20:36
我已经打开了一个跟踪问题。
– Bardi Harborow
17年3月15日在6:11
PR已在此处提交：github.com/EFForg/https-everywhere/pull/9110
–尼克·克拉弗♦
17 Mar 16 '17在19:39
@NickCraver Glad看到您可以解决问题。不过，我注意到一些奇怪之处：1.您在此处不包含meta。*。SE，将其重写为https：//不会更有意义。改为$ 1.meta.stackexchange.com？ （您的拉取请求仅重写https：//meta.*.SE，而不重写http：//meta.*.SE）2.您可能想要为* .meta.SE添加
–user2428118
17 Mar 17 '17在20:34
@ user2428118的好处-老实说，我真的只专注于解决立即重定向的问题。由于我们将全部使用HTTPS并在推出后使用带有安全cookie的HSTS，因此最终的结果是删除该规则集的绝大多数。当我们完全完成（聊天等）后，我们应该可以将其完全删除。甚至诸如lections.se.com之类的东西也被转移到另一个域（有人有任何建议吗？）以提高Cookie的安全性。二级域Cookie仅应在最后到达我们的网络，所有第三方服务都将停止运行。需要做的事情还很多 ：（
–尼克·克拉弗♦
17年3月18日在14:04
@ user2428118要明确：我非常欢迎任何人同时进一步清理规则（并且我将为他们提供尽可能多的信息），但是我认为我的主要努力应该是消除它。如果有人正在协调变更，请通过GitHub上的@NickCraver ping我，我将很乐意回答任何问题或复习我所能提供的一切。
–尼克·克拉弗♦
17 Mar 18 '14：15
@NickCraver，您的评论不清楚您是否知道：HTTPS-Everywhere的策略是仅在预加载域时才删除规则。仅凭HSTS还是不够的。
–小滴
17年3月21日在22:22
@NickCraver Pull Request被合并，完成。我们是否应将其标记为状态已完成。
–苏拉杰（Suraj Jain）
18年5月28日在16:50
#3 楼
状态已完成的错误如果不添加's'，则会破坏51个区域：
Stack Exchange问答网站建议：构造语言http：// area51。 stackexchange.com/ads/proposal/101265.png
^带有自动生成的“共享此”链接
^手动更改链接从http：//到https：//
要澄清：如果您进入Area 51提案页面，然后单击“共享”，然后复制嵌入的广告，然后将其发布到SE网络中的某个位置，图片将不会显示-它将是一个链接，但不会显示图片，如上所示。如果您将广告中的链接编辑为https：//而不是http：//，则会显示该图像。
这似乎是由列表中的4.）引起的，因为嵌入http：//链接。
评论
您指的是哪一页？如上面的步骤10所示，尚未为HTTPS启用区域51 ：)
–尼克·克拉弗♦
17 Mar 8 '17 at 19:52
@Nick，如果您转到Area 51提案页面，并获得广告内容，则至少在SE上不会显示图片。我很确定这是图像开关遗留下来的。我要看看它在SE之外是否仍然有效...
–数学
17 Mar 8 '17 at 19:53
所以您是在谈论访问https://area51.stackexchange.com？如果是这样，那还不行...请参阅上面的步骤10。这是在网络之后更容易移动的另一个代码库（因为那时我们可以在各处使用HTTPS）。
–尼克·克拉弗♦
17 Mar 8 '17 at 19:54
我不知道。我试图发布一个Area 51嵌入式广告链接作为答案，并且...在我编辑链接说https：//之前，该链接已损坏。
–数学
17 Mar 8 '17 at 19:56
我编辑以澄清的@NickCraver。
–数学
17年8月8日在20:00
啊，我现在已经明白了这个问题-可以很快地修复51区的问题-待命。
–尼克·克拉弗♦
17 Mar 8 '17 at 20:01
如果您对Area51页面进行了重新加载（以获取新的JavaScript），它应该呈现一个https：//图像以立即嵌入。缓存破坏器也是我以后必须在古老代码中解决的问题...
–尼克·克拉弗♦
17年8月8日在20:14
https和http加粗，现在看起来更具可读性。可以吗？
–苏拉杰（Suraj Jain）
17 Mar 22 '17 2:46
@NickCraver如何根据社区用户更正帖子中的链接？
–潘迪亚
17 Mar 25'6:13
#4 楼
状态已完成的错误如果您在要发布的链接或网站上使用
https，则不会从帖子正文中的URL解析问题标题（至少在预览中）。例如，通过
http://打开SO 
通过
https://打开SO 
通过此问题的
share按钮获取到帖子的链接。评论
有关系吗？
– Arulkumar
17 Mar 9 '17 at 14:37
共享按钮将像其所在的站点一样切换到https：//。例如，此帖子上的共享链接为https：//，而Stack Overflow尚未。
–尼克·克拉弗♦
17 Mar 9 '17 at 14:45
当前问题的@NickCraver共享链接未在预览中解析。
–αλεχολυτ
17 Mar 9 '17 at 15:21
@Arulkumar可能是重复的。
–αλεχολυτ
17 Mar 9 '17 at 15:42
徒手画圈+1。
–DaveTheMinion
17 Mar 10 '17在3:20
@alexolut啊-关于实际问题，我已得到解决，并指出要解决，它将在星期一尝试这样做。
–尼克·克拉弗♦
17 Mar 10 '17 at 21:52
嗯，这让我很烦。现在，修复已投入生产，感谢您提供信息！
–尼克·克拉弗♦
17 Mar 10 '17 at 22:30
@NickCraver的HTTPS链接没有获得标题的问题仍然在发生
–muru
17年3月11日在8:13
@muru现在应该解决-子/元/父关系将在明天的部署中得到解决（目前我正深入CSP标头分支/重构）。
–尼克·克拉弗♦
17年3月14日在20:33
#5 楼
bug在Android应用中，我的网站列表中固定了Mi Yodeya Meta，由于从
meta.judaism.stackexchange.com切换到judaism.meta.stackexchange.com，它已改为说Unknown Site meta.judaism而不是说Mi Yodeya Meta，当我单击它应用程序崩溃。评论
努力进行修复，因此人们不必手动执行此操作，但是现在您需要完全退出应用程序并重新登录（登录时，它会从Stack Exchange API请求所有站点的列表） 。
– Kasra Rahjerdi
17 Mar 16 '17 at 19:23
手动删除并重新添加它也可以解决此问题。
– SEJPM
17 Mar 16 '17 at 22:09
@KasraRahjerdi-自动修复程序有任何更新吗？刚刚收到有关Arqade的新报告：gaming.meta.stackexchange.com/q/12333/28182
–罗伯特尼克
17年3月30日在3:27
#6 楼
这不会破坏数千个通过http引用外部脚本的旧JavaScript代码段吗？示例：（注意：我怀疑没有人使用http链接到jquery，但这至少显示了问题） $("#test").text("hello world");
<script src="http://cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.js"></script>
<div id="test"><div>
与JavaScript库相关的大多数问题都引用外部脚本。 Three.js，Pixi.js等...
这是一个脚本，尝试查找具有http引用的代码段。它还列出了对jsfiddle，codepen，jsbin的提及，以防您要将其移动到摘要中。
评论
目前，只有在点击“运行代码段”按钮（而不是加载）时才会发生这种情况……我们仍然必须长期弄清楚那里的混合内容。
–尼克·克拉弗♦
17年3月13日在14:09
您应该使用协议推断的网址：//cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.js
–programmer5000
17年3月13日在21:02
@ programmer5000，最好使用https：//，它是HTTP / 2，在大多数情况下速度更快。
–尼克·克拉弗♦
17年3月14日在1:51
@NickCraver，有什么区别？我以为//的意思是“使用与页面相同的协议。浏览器会在请求中添加https:。所以有什么重要区别（不是我反对使用https：//而不是// //只是AFAICT） SO的结果将是相同的。
– gman
17年3月14日在15:08
@gman a）它们更难处理-许多代码和假设更难，并且b）在http：//上下文中，它们不会通过HTTP / 2传递，这是更快的。
–尼克·克拉弗♦
17年3月14日在20:35
如果您使用的是https://example.com，并且//example.com/*上有内容，它不是使用http / 2吗？
– UmurKontacı
17年3月14日在22:37
您还可能会发现该站点链接到根本不支持SSL。将所有HTTP URL重写为HTTPS将破坏所有不支持HTTPS的HTTP链接。
– jduncanator
17 Mar 14 '23在23:33
我会将其扩展到lorempixel.com之类的网站的所有链接，这些网站通常用于HTML和CSS代码段。但是能够为chrome片段制作gUM是一件好事;-)
– Kaido
17年3月16日在11:20
@nick这只是对目前使用http构建的站点的建议，但为了确保平稳过渡，这些站点将移至https。对于许多站点（例如我自己的站点，https：//programmer500.com），https是一个长期目标，但不能立即实现。我绝对支持https。
–programmer5000
17 Mar 18 '17 at 13:53
@ programmer5000我们有相对链接...由于：相对是什么，它们实际上使转换更加痛苦。什么啊什么是http？什么啊什么有有效证书？什么不？ JS复杂的检查，在其他情况下（例如电子邮件和移动应用）无法使用相同的路径。有很多弊端-我不建议自己做之后对其他任何人来说是中间步骤：)对于一个简单的网站（例如，仅一个网站），它可能是一个积极的方面，但是与其他部分相比，它变得非常复杂。
–尼克·克拉弗♦
17年3月18日在13:58
#7 楼
状态已完成的错误在帮助中心-特权页面中收到
https://错误，其中包含图像。图像仍然仅是http://。错误是：
明文： br />
该页面的某些部分不安全（例如图像）。因此收到警告。
评论
注意-我已经解决了这一问题，但我们必须在全球范围内访问帮助中心-谢谢！
–尼克·克拉弗♦
17 Mar 9 '17 at 15:18
@NickCraver“在全球范围内修复帮助中心”在这里也存在类似的问题：meta.stackexchange.com/help/privileges/approve-tag-wiki-edits-我们现在是否应该推迟与帮助中心联系？
–vcsjones
17 Mar 10 '17 at 20:19
@vcsjones Hmm privs需要更多的爱。我只是在网络上进行了所有内容/本地化的发布，但是特权需要另一个代码回填才能重新发布。注意星期一，谢谢！
–尼克·克拉弗♦
17 Mar 10 '17 at 21:51
@vcsjones这些应该现在解决-您是否还看到了？
–尼克·克拉弗♦
17年3月13日在12:36
@NickCraver进行了一些单击，到目前为止看起来不错。
–vcsjones
17年3月13日在13:54
#8 楼
错误状态已完成社区进行的将
meta.*.stackexchange.com更改为*.meta.stackexchange.com的编辑会将所有具有元链接的已关闭帖子发送到重新打开队列，因为它们已被编辑。这似乎很愚蠢，因为该帖子实际上并没有得到任何改善。评论
现在，此问题已解决，将按社区对帖子的编辑排除在排队条件之外
–m0sa♦
17 Mar 17 '17 at 10:27
那么匿名建议的修改呢？
–双AA
17年3月17日在11:20
#9 楼
错误状态已完成一旦在问题或答案下发布了许多评论，将提供将评论线程转换为聊天室的选项：
请避免在评论中进行过多讨论。您想自动将讨论内容移到聊天室吗？
用户确认后，会出现一条新评论：在聊天中进行讨论。对象已移动（404错误页面）。哦，如果您要解决此问题，只需很小的努力即可实现此功能请求。
#10 楼
错误似乎社区♦用户未通过自动修复更改协议推断的URL，即以
//开头的URL。 ruSO.meta链接中的文章：//meta.ru.stackoverflow.com/questions/305/
应更改为：不是。使用修订版4中的链接会导致打开带有不安全连接警告消息的页面。
使用显式协议的网址已成功更改，您可以看到它，例如在这里。
#11 楼
bug在大多数stackexchange.com域中，您会自动从HTTP重定向到HTTPS。例如。 http://meta.stackexchange.com导致https://meta.stackexchange.com。
至少有三个子域不是这种情况：
http://area51.stackexchange.com状态截至2019年1月9日完成
http://api.stackexchange.com status-declined
http://data.stackexchange.com状态已完成，截至2018-10-01
是否有任何计划要对此进行更改，或者该状态是按设计的？
评论
奇怪的是，讨论区51的http://area51.meta.stackexchange.com会自动重定向到https://area51.meta.stackexchange.com，但不会重定向到Area 51主站点。
– Arulkumar
17年8月9日在6:19
@Arulkumar那是因为A51 Meta使用* .meta.stackexchange.com通配符规则，因此它会自动重定向。
– iBug说恢复莫妮卡
18 Mar 6 '18 at 9:59
现在，区域51进行了重定向，但是没有计划强制使用API（尽管我们支持https：//）-如果这样做的话，这会使某些人失望。
–尼克·克拉弗♦
19年1月9日在17:27
#12 楼
错误在我提交后，在Qubes的Area51提案页面中，
评论
是的-我们还没有这样做-它将在列表10中排在后面
–尼克·克拉弗♦
17年3月13日在12:38
#13 楼
状态已完成来自示例新闻通讯的弹出窗口为空...
来自“喜欢此网站？”示例新闻通讯广告是通过HTTP在iframe中加载（并阻止）的，因此您所看到的只是空白的lightbox / popup / dialog /任何您想调用的广告：
时事通讯页面本身确实支持HTTPS，因此将链接更改为HTTPS即可解决：
/>
评论
知道了，将在星期一修复-谢谢！
–尼克·克拉弗♦
17 Mar 12 '17 at 0:35
该问题将在缓存在下一个小时到期后修复。
–尼克·克拉弗♦
17年3月13日在12:36
@NickCraver仍然不能为我工作。
–αλεχολυτ
17 Mar 20 '17在3:11
@Nick在“编辑配置文件”首选项部分中仍然损坏：i.stack.imgur.com/o2UmC.png您能在那里也将其修复吗？
–影子向导正在接种疫苗
17年3月20日9:00
@ShadowWizard 2个月了，尽管状态已完成，但问题仍然存在
–αλεχολυτ
17年5月27日在7:58
@alexolut并不是真的，此答案中描述的问题是固定的（因此状态完成的标记正确），您发现的是另一个问题，因为它发生在不同的地方。由于Nick在这里忽略了我们的评论，因此您可以发布有关此问题的新错误报告。
–影子向导正在接种疫苗
17年5月27日在13:44
@ShadowWizard具有相同行为的不同问题？
–αλεχολυτ
17年5月27日在13:46
@alexolut完全是。通常，这样的两个错误报告将作为重复项关闭，但在这里我们仅用“非标准”方式将其标记为完成来处理答案。
–影子向导正在接种疫苗
17年5月27日在13:47
#14 楼
关于SSL和Web服务器安全性我有一些知识，但是我会在此信息的段落上写上段落，而是将所有可能引用此链接的人都引用到以下链接：scan meta。 stackexchange.com-Mozilla的观测台
该网站使用其他网站，例如但不限于SSL LABS和HTbridge
是“ F”：
评论
是的，老实说，我一点也不担心。您正在测试许多零件移动的第一阶段，预计所有零件都未安装到位。第一阶段是针对所有流量进入HTTPS，在这里可以得到更好的评分：ssllabs.com/ssltest/…例如，如果我立即启用仅保护cookie而不进行迁移，则将注销数百万用户。我碰巧认为这是个坏主意:)
–尼克·克拉弗♦
17 Mar 14'20:42
OTOH SSL Labs报告A。
–马丁·施罗德（MartinSchröder）
17年3月14日在21:16
[延期状态]然后呢？
–罗伯特尼克
17 Mar 16 '17 at 0:21
对于meta.stackexcange.com，我得到D-；对于StackOverflow，我得到F？
–stevefestl
17年5月1日在7:53
#15 楼
错误？当在聊天室（SE）中上传图像时，发布到聊天室的链接是http而不是httpS。通过http和https聊天。
解决这个问题并不困难。
评论
还值得注意的是，社区机器人没有将Stack Imgur的HTTP图像转换为HTTPS（尽管可以通过添加“ s”将其转换）。
–加利弗雷扬
17年7月12日在7:26
#16 楼
bug主持人工具Meta主持人仪表板中的总页面浏览量未显示2017年3月16日（完成切换到* .meta.stackexchange.com的日期）之前的任何数据。 >
#17 楼
我当前在以下位置收到证书警告：在查看建议的修改时，如何分辨与之相关的问题或答案？从Chrome浏览器，但很奇怪没有让他们直接访问https://meta.security.stackexchange.com：
评论
您在尚未准备好之前就已经加载了它：）请参阅帖子中的列表-我们暂不准备使用metas。但是，我们今天开始，并且首先是security.meta.stackexchange.com。
–尼克·克拉弗♦
17年3月13日在14:10
您还能重现此错误吗？
– SEJPM
17 Mar 14 '17 at 20:03
@SEJPM不，它现在似乎正在工作。现在，在安全性元数据上也没有了“不安全”的字样。
–杰森C
17 Mar 14 '21：46
#18 楼
通过HTTP访问的站点的共享链接仍然提供HTTP链接（实际上是不一致的：MSE似乎总是提供HTTPS，SO总是似乎提供HTTP），这很有意义，除了您可能要考虑强迫它们提供HTTPS链接而是因为：站点中仍然存在大量HTTP链接（例如，Google链接大多转到HTTP，旧的浏览器书签和自动完成的URL等），这意味着很多人获得非共享链接。
这将有助于减轻帖子中的HTTP→HTTPS转换的负担。
有一些令人信服的证据。以SO为例，例如，自3月10日（本公告发布之日）以及大约8个小时前（SEDE更新的良好时机）：
已创建了7,938个帖子其中以某种形式指向stackoverflow.com的链接。
其中7,616个使用HTTP而不是HTTPS。
占96％的新SO链接帖子最终占它们中的HTTP链接。
要明确，并不是说所有链接都是共享链接的结果。这些数字表明很多人正在通过HTTP访问（因为他们发布的链接将是共享链接或从浏览器栏中复制+粘贴）。但是对我来说，共享链接可能应该转换。
以SO为例，我认为其他地方的模式也是如此。为此，您可能需要重新访问此请求。
为此，您可能还希望在某些时候开始提供从HTTP页面到HTTPS的重定向。这将解决“从地址栏复制链接”的结尾，以及所有您无法控制的外部HTTP链接。
评论
在默认为HTTPS的站点上，共享链接为HTTPS。这与您访问页面无关，它们（有意地）符合规范。他们会像网站一样转移。
–尼克·克拉弗♦
17 Mar 20 '17 at 12:21
@NickCraver啊，我知道了，所以还没有转移（这与第二个待办事项列表中第5项旁边未完成的情况保持一致）？这就是为什么链接仍然在那里的HTTP，对吧？我可以看到MSE和MSO都有HTTPS共享链接，这些链接也与您发布的进度列表一致。
–杰森C
17 Mar 20 '17在21:12
#19 楼
状态完成：已移至https://area51.meta.stackexchange.com无法通过HTTPS访问Area51讨论区
尝试访问https：// area51。 meta.stackexchange.com/给出错误。
屏幕截图：
评论
A51代码库在更新SE的其余部分时遇到问题，消息为11。
–内森·塔吉（Nathan Tuggy）
17 Mar 20 '17在10:03
area51.stackexchange.com仍在待办事项列表中。
– DavidPostill
17 Mar 20 '17在10:29
尚未完成-在上面的列表中尚未完成...
–尼克·克拉弗♦
17年3月20日在12:20
有很多代码需要为此移动-但如果时间允许，它将被移至area51.meta.stackexchange.com。
–尼克·克拉弗♦
17年4月16日在16:49
@NickCraver Uhm，我偶然发现了另一个有关area51和SSL的问题...尝试此链接
–撤消
17-6-29在20:43
#20 楼
状态完成的注释中的快捷链接（例如
[su]）仍解析为http://，而不是https://。评论
像这样：[su] =超级用户
–马丁·普里克里（Martin Prikryl）
17年5月24日在12:20
#21 楼
bug在Ques的Area51投标页面中收到
https://错误，其中包含一个脚本。尽管脚本已通过https：https://edge.quantserve.com/quant.js 仍以纯文本形式显示，但错误仍会导致错误： br />此页面的某些部分不安全（例如图像）。
评论
并非导致错误的Quantcast脚本，而是通过HTTP加载的各种Gravatar用户图像。我自己的Gravatar图标在顶部栏中也会发生这种情况。
–user2428118
17 Mar 12 '17 at 15:15
@ user2428118奇怪，我使用了Firefox的“开发人员”>“网络”工具，它显示了该特定脚本。 （注意：我还启用了HTTPS Everywhere扩展）
–user139336
17年3月13日在11:42
@NickCraver stackexchange.com仍通过HTTP提供Gravatar图像。
– Bardi Harborow
17年3月18日在1:37
#22 楼
一旦支持TLS，就需要更新ssl摘录和wiki（并且标记可能应该从ssl重命名为tls，但这是不同的讨论）。评论
我们已经在Meta Crypto SE上对此进行了讨论，我们认为这是不值得的。
– SEJPM
17年3月15日在16:25
#23 楼
元站点上的主要标签恢复为“ http”如果在帖子中键入
[tag:foo]或[meta-tag:bar]之类的内容，您将看到类似这样的内容
并链接到
site.stackexchange.com/questions/tagged/foo或site.meta.stackexchange.com/questions/tagged/bar 1，适当。
基于大约10个社区的抽样调查，
如果您使用https转到主要（非元数据）网站，
并使用tag2 Markdown，
链接到相应的
https
questions/tagged/tag URL。 按预期。
在我测试过的社区中，如果您使用https转到元站点，
并使用元标记Markdown，
您将获得一个链接到相应的
https://site.meta.stackexchange.com/questions/questions/tagged/tag URL。 如预期的那样。
在我测试过的许多社区中，如果您访问元站点，
使用https并使用标记Markdown，您将获得一个链接，
http://site.stackexchange.com/questions/tagged/tag。 这是错误的。
这些社区正确无误：
元堆栈交换
（元）超级用户
（元）信息安全
我测试过的所有其他社区（包括堆栈溢出）都弄错了。
___________1或
meta.sitename.com/questions/tagged/bar，对于这些社区（堆栈溢出，超级用户，服务器故障，询问Ubuntu等）。
不符合
site.stackexchange.com模板。2个非元站点无法识别[meta-tag:tag] Markdown。评论
现在肯定正确吗？只有正确完成转换的社区才是切换到HTTPS AFAIK的社区...
–蔡
17年3月19日在10:19
@Cai：好吧，我不知道完整的计划，但是（1）我觉得应该先完成Meta Stack Exchange，StackOverflow和Information Security，然后（2）五年来一直致力于使整个网站对https友好。让https页面显式生成一个指向http页面（在网站内）的链接似乎是他们很早以前就想解决的问题。
–斯科特
17年3月19日在18:54
否，不是堆栈溢出...当前唯一启用了https的主要站点是Super User and Security SE
–m0sa♦
17 Mar 20 '17在9:04
#24 楼
status-planned仅观察一下：
在Stack Exchange特权中，某些特权页面中包含其他Stack Exchange帖子的链接。这些链接仍为
http://，但单击链接时，它将以https://打开。 不会造成任何问题，但是更新这些
http://链接也将与链接保持一致。示例特权页面：
社区Wiki页面的底部，有
http://链接另请参见“社区Wiki”帖子是什么？
评论
我们将网络中的所有链接重新烘焙为到处都是https：//（以消除用户的301）。我们将在所有问答环节结束后再进行此操作，因为我们可以全盘假设https：//，重做一次，并简化所有涉及的逻辑。
–尼克·克拉弗♦
17 Mar 15 '17 at 22:54
为什么要回滚自动编辑？为什么会有无用的重定向？
–影子向导正在接种疫苗
17年8月2日在14:44
@ShadowWizard在修订版4中查看我的评论：在实际的特权页面中，https url尚未更新，因此我在帖子中更改了http url。该问题尚未解决。
– Arulkumar
17年8月2日，14：45
我懂了。好吧，仍然不确定我们是否应该照原样引用链接。很清楚您的要求。
–影子向导正在接种疫苗
17年8月2日在14:46
#25 楼
bug如在Area 51 Meta上所述，在Area 51上的OpenID登录仍然会通过不安全的HTTP请求（并且如果该请求被重写为使用HTTPS（例如，通过HTTPS Everywhere）则将中断）。 >
我已将后一问题报告给HTTPS Everywhere开发人员，他们现在为有问题的URL添加了排除项。但这无法解决登录URL不安全的根本问题。
（请注意。我大约90％的人确定解决此问题的唯一方法就是将遗漏的
s添加到OpenID在Area 51代码库中返回URL参数，从表面上到达正确的OpenID身份验证端点的意义上讲，让HTTPS Everywhere重写URL以使用HTTPS确实可行，但是auth代码随后将重写检测为意外的URL修改并中止登录过程。）#26 楼
功能请求作为我今天早些时候写的问题的继续（HTTP-> HTTPS脚本并没有改变一切）：
我们可以让社区用户运行脚本吗？要将所有链接转换为也可以使用HTTPS协议？归功于Glorfindel
MSO发生459次，其中有735次。
这些实例太多，无法手动处理，并且在手动完成时会不成比例地破坏首页。
编辑：如Stormblessed所指出的，也没有被转换。它们是
data.SE和http://stackexchange.com，后者在MSE上出现了1416次。#27 楼
错误在有刻度的网站在用户页面的版主标签，例如：https://stackoverflow.com/users?tab=moderators，有一个“民选【同期】”链接下方每个用户。该链接仍在HTTP中。
评论
这是个问题吗？默认重定向到https。它只会导致本来可以避免的额外302响应。除非我想念什么
–rene
20 Jan 1 '20 at 19:14
这篇文章已有2年多的历史了，没人真正关注它。通过创建新问题更好地解决新错误。
– animuson♦
20年1月1日，19：33
@animuson好吧，这是一个很小的问题。也许不值得。
–user23013
20年1月1日，19：36
#28 楼
通过HTTP可以继续使用api.stackexchange.com吗？评论
该计划是将所有流量都强制发送到https：//-但是我很好奇您为什么要问...
–尼克·克拉弗♦
17年3月14日在20:37
实际上主要是因为这样的事情。如果使用强制HTTPS，则在没有适当框架和库的情况下使用SE API可能会比较棘手。可以在netcat中键入HTTP请求，但不能键入HTTPS请求。
– Vi。
17 Mar 16 '17 at 12:07
#29 楼
状态已完成明显的错误
HTTPS转换似乎已取消新闻通讯订阅在网络的其余部分，我建议进行调查以修复它或宣布人们将需要重新订阅他们的新闻通讯。 （最好的IMO；这是我们要避免的静默下降。）
评论
我现在正在研究这个问题，希望今天能修复所有数据。
–尼克·克拉弗♦
17 Mar 20 '17 at 13:58
#30 楼
bug主持人工具用西班牙语西班牙语Meta StackOverflow中主持人仪表板显示的总页面浏览量根本没有显示任何数据。
评论
对于11. chat，如何将chat.so迁移到chat.se并减少麻烦？@Braiam确实不是一个问题，所有3个问题都是相同的解决方案。但是，合并3个数据库，房间列表，用户，代码假设，弄清楚所有时间的重定向等问题会产生很多问题。以任何方式赢得胜利：)
在Google方面，他们在如何帮助SEO方面做了大量工作，但没有迹象表明它可以起到很大帮助。因此，WMT不正确支持它的事实也不会令我感到惊讶。 Google希望使用HTTPS，但还不足以使人们更容易使用它
您是要使用错误报告作为答案吗，还是将单独的问题标记为bug和ssl或其他？
＃3可能会忽略与编辑器预览有关的与内容安全相关的小错误。到轮毂！
@ale答案很好，谢谢！
Hot meta帖子（位于meta.SO本身）未与https链接（不确定是否进行缓存，但是已经有一段时间了。）。
您如何计划将元数据移动到site.meta.se？您是让社区机器人四处编辑它们，还是由用户来编辑他们的帖子？
@NickCraver我从MSE的这里到其他站点都收到了粘性HTTPS。例如。我来到这里，它将URL重写为HTTPS，我使用超级对撞机转到其他地方，URL保持HTTPS，然后当我转到其他站点的meta时，遇到证书错误。我知道那不是故意的行为吗？我在Firefox 51.0.1中看到了它，并在一个私有窗口中复制了它。我没有使用HTTPS Everywhere扩展。
后续行动：Chrome 56.0.2924.87不会发生。也许是Firefox错误？ （我不确定我是否想使用IE打破常规……）
@PeterMortensen什么是“这”？假装我对您的始终加密的超级秘密编程语言一无所知:)有什么问题？该库是否根本不支持HTTPS？还是...另一个问题？
答：是汤。
除了@PeterTurner Nick，我认为它已正确删除，因为它无法回答正在SE的HTTPS部署中寻找特定技术问题的问题。作为单独的元问题比在这里作为答案更合适。
您可能需要添加Content-Security-Policy-Report-Only标头，以便用户自动报告混合内容和类似问题。您也可以添加一个“ upgrade-insecure-requests” CSP标头，尽管在完成所有其他操作之前这并不理想。
@John尚未完成-他们仍然必须迁移SO，stackexchange.com，Area 51和聊天。他们还需要在第一个列表上执行＃10-12。