问题标签 [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 - 当我的代理出现内部错误时,返回 502 状态码是否正确?
我写了一个小代理,我想知道502 Bad Gateway
当代理服务器本身有内部错误时,我返回错误是否正确。RFC似乎说只有在另一端的服务器给出错误响应时才这样做。
服务器在充当网关或代理时,在尝试满足请求时从它访问的上游服务器接收到无效响应。
我认为这意味着,例如,如果上游服务器设置的content-length
标头与响应正文长度不同,我们应该设置一个502
错误,即当响应无效时。
我是否误解了 RFC?
html - 如何在链接或表单中指定 DELETE 方法?
Rfc2616 列出了除 GET 和 POST 之外的许多方法,例如 DELETE、PUT 等。不过,html 表单中的方法字段似乎只允许指定 GET 或 POST。
是否可以在使用不是 GET 或 POST 的请求方法的 html 页面中创建链接或表单?
http - 传输编码分块的 HTTP 响应中的最大块大小是多少?
w3.org (RFC2616)似乎没有定义块的最大大小。但是没有最大块大小,就没有块扩展的空间。必须有一个最大块大小,否则我不能忽略块扩展,因为如果无法理解,我建议这样做(引用:)"MUST ignore chunk-extension extensions they do not understand"
。
rfc2616 - 无效 POST 参数的错误代码
当 POST 请求具有无效参数时,返回的正确错误代码是什么?说:一个表单为一个事件获取数据,但提供的日期是过去的;或表单为用户注册获取数据,但提供的名称是数字或任何无效的人名。
http - http1.1 rfc2616中带引号的字符串的确切语法和语义是什么
在作为 HTTP/1.1 标准的rfc2616中,带引号的字符串定义如下。
有了这个定义, "" 似乎是一个 TEXT,因此<">\<">
(quote, backslash, quote) 似乎是一个有效的带引号的字符串。但这与正确使用反斜杠作为转义字符相矛盾,甚至可能导致无法明确地确定引用字符串的结尾。我的错误在哪里?
RFC 还指出
我已经阅读了即使带引号的字符串中的 LWS 也可以被 SP 替换的解释。如果我从字面上理解 RFC,那就是它所说的。我对此感到困惑,因为这意味着引用的字符串“”、“\n”、“\n\t \t \t”……都是一样的。那些引用的字符串真的不能在语义上区分吗?
http - 使用 Accept-charset HTTP 标头
使用其中一种的区别和优势是什么:
相对:
第一种形式是否符合 rfc 2616?
注意:可以是 json 或 xml 等。
http - 如何在 HTTP1.1 中进行符合标准的 GET 查询
简而言之:如何以符合 HTTP1.1 标准的方式来 rfc2616 对像http://example.com/?query这样的 URL 进行 GET 查询
维基百科说
在rfc2616 中它说
只有 abs_path 和 absoluteURI 与 GET 请求相关。
abs_path
其中 abs_path 实际上来自禁止“?”的uri rfc,因为 abs_path 实际上是查询部分之前的 uri 部分。所以看起来维基百科的变体在语法上是不正确的。
绝对URI
为此,uri rfc 说
因此可以将这样的查询放入 Request-URI 中,但不幸的是 rfc2616 不允许为未与代理交谈的客户端传输 absoluteURI。可以通过网络服务器以符合标准的方式接收它,但实际上不可能通过浏览器或其他客户端以符合标准的方式发送它。
rel_path
令我惊讶的是rfc2616提到了一个“?” 在 rel_path 中,但rfc2396也不允许这样做,实际上也不可能将 rel_path 放在 http 请求的某个位置,因为 rel_path 规则在 rfc2616 中的任何地方都没有在语法上使用。
所以我的问题是,如何以符合标准的方式提出这样的请求,所有浏览器是否都违反了标准?
http - 应该使用哪些 HTTP 错误代码来指示内部错误?
我开发了一个 REST 应用程序,我的应用程序的一个案例是:
用户在服务器端进行操作。一切顺利,服务器正确接受数据,但是发生了一些错误,就像与数据库通信一样。我不想用错误代码返回它我想用成功代码发送它,但有一个指示错误的正文。我想发送 500、404 等的错误代码。我的设计是否正确,我应该为我的案例返回哪个状态代码?
http - 我可以用逗号分隔所有 HTTP 标头吗?甚至授权?
我正在阅读 HTTP 1.1 RFC,但无法回答以下问题。
我们有这个标题:
这引起了麻烦,因为 Rails 3 授权解析器由于“,”字符而错误地解码了字符串。我知道这很不常见,但我们使用这个 Apache httpd 配置添加它:
响应标头附加到任何现有的同名标头。当新值合并到现有标题时,它与现有标题用逗号分隔。这是为标头提供多个值的 HTTP 标准方法。
但我认为这个 Authorization 标头不正确。RFC 定义不允许这样做。但有些标题允许逗号分隔的列表。我不确定这是否是所有 HTTP 标头的一般规则。
我正在HTTP 1.1 RFC 中寻找一个段落来证明我的想法这是不正确的。我已经发现了“这仅对可以分离的标题有效”的内容,但这不是证明。
当且仅当该头字段的整个字段值被定义为逗号分隔列表[即,#(values)] 时,具有相同字段名称的多个消息头字段可能出现在消息中。必须可以将多个头字段组合成一个“字段名称:字段值”对,而不改变消息的语义,方法是将每个后续字段值附加到第一个字段值,每个字段值用逗号分隔。因此,接收具有相同字段名称的头字段的顺序对组合字段值的解释很重要,因此代理不能在转发消息时更改这些字段值的顺序。
这真的没有意义,但我正在寻找一个明确的证据。
asp.net-mvc - 为什么 System.Web.Mvc.HttpVerbs 类缺少 TRACE、CONNECT 和 OPTIONS?
RFC 2616 HTTP/1.1 定义指出存在以下常见的 HTTP 方法:
GET、HEAD、POST、PUT、DELETE、TRACE、OPTIONS、CONNECT
但是System.Web.Mvc.HttpVerbs枚举缺少 TRACE、OPTIONS 和 CONNECT。
我有一个动作过滤器,它从请求中提取 HttpVerb 以做出某些决定(例如,如果一个请求是 PUT'ing 基本类型 A 的模型,那么我设置了一些数据),所以这个实用程序代码正在为最后三个请求抛出 ArgumentOutOfRangeException(主要是 OPTIONS - 看起来它来自谷歌翻译):
不知道如何解决这个问题 - 有什么想法吗?
我能想到的唯一一件事是更改所有引用代码以首先检查原始 HTTP 方法,然后仅在不是 TRACE、OPTIONS 或 CONNECT 时调用该实用程序。这有点骇人听闻。
为什么枚举类中缺少它?有什么具体原因吗?MVC 不能处理这些类型的请求吗?
通过 OPTIONS 方法的声音,它甚至不应该到达 MVC,它应该由 IIS 本身处理?