问题标签 [rfc2616]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
http - HTTP 重定向是否需要完整的 URL?
对于 http 重定向,比如 302,是否必须返回新页面的完整 url,包括http://
或者是否可以只向根 url 发送相对地址,例如/my/view
?
我试图在https://www.rfc-editor.org/rfc/rfc2616#section-10.3.3阅读 rfc 2616,但可以找到任何明确的内容。
此外,是否存在与此相关的已知浏览器错误?
caching - RFC2616 13.3,浏览器历史和缓存
我一直在努力解决浏览器历史与缓存和RFC2616 13.13的整个问题
RFC 的这一部分是否意味着如果用户在浏览器中“返回”,例如,它应该始终显示来自其本地存储的页面,忽略任何缓存指令,除非用户另有配置?
因此,在浏览历史记录时重新加载页面的浏览器,即使缓存指令指示它这样做,也不符合规范?规范说这是不好的,因为“这将迫使服务作者避免使用 HTTP 过期控制和缓存控制,否则他们愿意。”
此外,即使指令可能指示浏览器不要缓存,例如 using Cache-Control: no-store
,它可以/应该将其存储在它的历史缓存中?
从我读过的内容来看,除了 Opera 之外,似乎大多数浏览器都违反了标准。这是因为重新显示包含历史敏感数据的页面的安全问题被认为比标准所讨论的问题更重要吗?
如果有人能够对这个领域有所了解/澄清,我将不胜感激,谢谢。
http - 嵌入式 HTTPS 服务器。应该如何处理重定向,我应该提供 HTTP 吗?
背景
我已经实现了一个 HTTPS 服务器,它位于一个硬件内部,用于设备的安全远程配置。为了实现这一点,我使用了现有的轻量级嵌入式 TCP/IP 堆栈以及开源 SSL 库。位于其之上的 Web 服务器完全由我从头开始编写。(这可能看起来像是对轮子的重新发明,但就我们的目的而言,它需要非常轻量级并且具有非常狭窄的特定功能集。例如,与我们正在使用的嵌入式 RTOS 以及 ROM“文件系统”的兼容性。这是一个只有几百 KB 可用于 HTTP(S) 会话和 SSL 上下文的系统,而不是多少兆字节。在考虑了所有因素并查看了各种其他产品之后,创建我自己的产品是有意义的)。该 Web 服务器只需要支持 5 到 10 个同时套接字连接(即 5 到 10 个并发或持久 HTTP 连接),这大约是硬件可以处理的数量。这很好,因为它是专为一两个人访问和管理盒子而设计的。
目前,它现在一切正常。我已经对其进行了编码,以实现我认为 HTTP 1.1 所必需的尽可能多的 RFC2616。目前,它只是监听五个 HTTPS 端口(443),我还没有实现任何从端口 80 重定向的东西。
第一个问题 - 重定向
我看过无数关于从 HTTP 重定向到 HTTPS 的文章,但我读到的所有内容都涉及如何配置现有的和传统的 Web 服务器来执行此操作。我想要解决的是在协议级别使用了哪些技术,因为我必须以编程方式实现这一点。
常见的方法似乎是发出 301 / 302 响应。所以,我想到的策略是,假设我有八个同时请求的资源:
在端口 443 上侦听 HTTPS 连接。最多可同时使用六个 HTTPS 连接(六个套接字)。
在端口 80 上侦听 HTTP 连接,最多有两个 HTTP 连接(因此端口 80 上有两个套接字)可用。对于端口 80 上的套接字,不会真正访问真正的 Web 服务器。相反,我会一直从套接字读取,直到看到
\r\n\r\n
或\n\n
看到(指示请求标头结束),然后发回 301(或 302)响应,在我的代码中它几乎是一个硬编码const char*
字符串。然后,关闭套接字。这两个端口 80 套接字的存在纯粹是为了重定向。
这个策略听起来合理吗?
目前我唯一不确定的是在 301 / 302 响应中包含重定向 URL。这个硬件“盒子”是一个可以放在房子里或路由器后面某处的设备,可能通过动态 DNS 服务等访问。那么,我将如何以编程方式确定它的“外部世界”等效 HTTPS URL?也许通过结合使用请求 URI 中的内容和host:
原始 HTTP 请求标头的字段?
如果上面有任何问题,那么我的下一个最佳想法是返回一小段 HTML,其中包含一些 JavaScript,通过从浏览器获取 URL 来执行 HTTPS 重定向(特别是我会使用哪些 JavaScript 方法打电话来做这件事我不记得了,但我已经做了很久了)。(目前我还不确定 SSL 证书到底是如何工作的,因为没有可以指定的特定域,但我稍后会越过那座桥,也许在一个单独的 SO 问题中。)
第二个问题 - 提供 HTTP 和 HTTPS
这可能更像是一个设计问题,或者取决于客户想要什么,而不是一个编程问题——但我想我还是把它放在这里看看人们有什么意见。我的问题是客户只是简单地声明盒子“应该有 SSL”,但仅此而已。例如,我不知道他们是否期望能够为最终用户提供是否使用 SSL 的选择。现在在真正问他们之前,我只是在预测可能会被问到什么,我想事先用一些知识和答案武装自己。换句话说,写规范的人为这个“只想看挂锁”和“想要SSL”,这显然是件好事;
首先,我知道 SSL 没有半途而废的解决方案:你要么需要全部,要么什么都没有。换句话说,假设我决定尝试通过 HTTPS 提供重要的东西来减少我的小处理器必须做的工作,但我通过 HTTP 提供图像和 CSS 文件。在做了一些阅读之后,我现在确切地知道为什么这是一个绝对的禁忌,原因有很多。
但是,如果我让最终用户能够在某个初始登录页面选择 HTTPS 或 HTTP 会怎样?选择“HTTPS”将重定向到安全的 HTTPS 登录页面。例如,如果用户在从手机访问盒子时为了提高访问速度而选择牺牲安全性,这可能是一个有用的选项。此初始页面可能提供“安全登录”和“标准不安全登录 - 不建议”或类似内容。显然,就用户而言,这会带来一个漏洞,但它是否也会危及 SSL 连接?我的意思是,由于这个初始登录页面必须通过 HTTP 提供服务,因此理论上攻击者可能会破坏它,以便交换按钮——诸如此类。因此,HTTPS应该意味着HTTPS从一开始就对吗?鉴于我已经设法将 HTTPS 硬塞到这个东西中并使它工作,并且考虑到它是专门为与现代浏览器(IE8/9,FF)一起使用而设计的,那么正常的 HTTP 访问应该是什么实际的原因呢?作为替代方案提供?
http - “最保守”转换为 GMT?
HTTP 1.1 RFC (2616) 的第 19.3 节“容忍应用程序”关于从 HTTP 客户端应用程序解析日期的主题说:
如果 HTTP 标头错误地携带了时区不是 GMT 的日期值,则必须使用最保守的可能转换将其转换为 GMT。
两个问题:
这是否意味着服务器必须将非 GMT 日期值转换为 GMT?或者这是否意味着如果(可选)它选择将非 GMT 日期值转换为 GMT(而不是拒绝它),那么它必须使用最保守的可能转换?
“最保守的可能转换”是什么意思?
编辑虽然这是一个老问题,但如果有人知道答案,我仍然很感兴趣。
http - linux下读取http包
我正在阅读 RFC 2616,我想查看所有 http 数据包。哪个工具最适合这个?
web-services - 303 响应正文中的超链接
在 POST 之后进行 303 重定向时,RFC 2616提到在响应正文中添加超链接(即 POST 的 303 响应正文,而不是后续 GET 对新创建资源的响应)。
10.3.4 303 见其他
可以在不同的 URI 下找到对请求的响应,并且应该使用该资源上的 GET 方法来检索。此方法的存在主要是为了允许 POST 激活脚本的输出将用户代理重定向到选定的资源。新的 URI 不是原始请求资源的替代引用。303 响应不能被缓存,但对第二个(重定向)请求的响应可能是可缓存的。
不同的 URI 应该由响应中的 Location 字段给出。除非请求方法是 HEAD,否则响应的实体应该包含一个简短的超文本注释,其中包含指向新 URI 的超链接。
我对此有两个问题:
是否有任何实现(浏览器或其他)在 303 的主体中使用这样的链接?
如果在正文中添加链接,最合适的链接关系是什么?
rel="self"
,rel="alternate"
? 两者似乎都不完全合适。我意识到这样的事情可能没有标准的链接关系,如果是这样,那就这样吧。
http - 禁止某些并发 GET 请求是否违反 RFC 2616(安全/幂等性)?
我目前正在讨论关于禁止给定资源上的并发 GET 请求是否构成违反 RFC 2616 的问题(尤其是 GET 方法所需的幂等性和安全性,§9.1)。
例如; 如果我的服务器同时收到 GET /data/?dataId=123456 两次,您是否认为一个或两个请求返回错误消息违反了安全性或幂等性?
根据我的理解,RFC 指定相同的请求在再次调用时应该产生相同的结果。然而,我还没有看到任何关于并发请求的行为是可以接受的。
我的感觉是不允许并发 GET 访问(在给定资源上,当然不是一般规则)并不构成违反 RFC。返回 423 响应代码或 500(虽然不是很优雅),甚至是 429 或 420(尽管含义略有不同)对我来说似乎是可以接受的。
但是,我想知道是否有有效的论据证明 RFC 否认这一立场。
在此先感谢/最好的问候
http - “无缓存”与“max-age=0,必须重新验证,代理重新验证”
Cache-Control: no-cache
HTTP 响应与vs有什么区别Cache-Control: max-age=0, must-revalidate, proxy-revalidate
?
浏览器是否将其视为相同?
http - URI 是否不区分大小写?
在比较两个 URI 以确定它们是否匹配时,客户端
应该使用区分大小写的字节对整个
URI 进行逐个字节的比较,但以下情况除外:
我在Http Rfc中阅读了上面的句子我认为 Url 不区分大小写,但我不明白这意味着什么?
http - HTTP 响应数据超过内容长度时的代理/网关行为
当 http 服务器发送数据大小超过内容长度的 HTTP 响应时,代理/网关应该如何表现?将其作为不符合 RFC 的规定删除是一种可行的方法,但看起来今天有相当多的实现/部署具有这种行为,而这种变化最终会破坏这些 URL。
将非常感谢任何见解/指针。
谢谢,开发