Independent Submission E. Fokschaner
Request for Comments: 8565 1 April 2019
Category: Informational
ISSN: 2070-1721
Independent Submission E. Fokschaner
Request for Comments: 8565 1 April 2019
Category: Informational
ISSN: 2070-1721
Hypertext Jeopardy Protocol (HTJP/1.0)
超文本危险协议（HTJP/1.0）
Abstract
摘要
The Hypertext Jeopardy Protocol (HTJP) inverts the request/response semantics of the Hypertext Transfer Protocol (HTTP). Using conventional HTTP, one connects to a server, asks a question, and expects a correct answer. Using HTJP, one connects to a server, sends an answer, and expects a correct question. This document specifies the semantics of HTJP.
超文本危险协议（HTJP）颠倒了超文本传输协议（HTTP）的请求/响应语义。使用传统的HTTP，用户可以连接到服务器，提出问题，并期望得到正确的答案。使用HTJP，用户可以连接到服务器，发送答案，并期望得到正确的问题。本文档指定了HTJP的语义。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8565.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8565.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Comparison with HTTP . . . . . . . . . . . . . . . . . . . . 3
4. Response and Request Semantics . . . . . . . . . . . . . . . 4
4.1. Applicability of Postel's Robustness Principle . . . . . 4
4.2. Identifying the Server Associated with an HTJP Response . 5
4.3. Temporal Considerations . . . . . . . . . . . . . . . . . 5
4.4. Pseudo-Valid HTJP Messages . . . . . . . . . . . . . . . 6
4.5. HTTP Responses That Are Not Requestable . . . . . . . . . 6
5. Caches and Proxies . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7.1. Securing HTTP against HTJP . . . . . . . . . . . . . . . 7
7.1.1. Anti-HTJP-Nonce Header . . . . . . . . . . . . . . . 8
7.2. HTJPS . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Hypertext Double Jeopardy Protocol . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Comparison with HTTP . . . . . . . . . . . . . . . . . . . . 3
4. Response and Request Semantics . . . . . . . . . . . . . . . 4
4.1. Applicability of Postel's Robustness Principle . . . . . 4
4.2. Identifying the Server Associated with an HTJP Response . 5
4.3. Temporal Considerations . . . . . . . . . . . . . . . . . 5
4.4. Pseudo-Valid HTJP Messages . . . . . . . . . . . . . . . 6
4.5. HTTP Responses That Are Not Requestable . . . . . . . . . 6
5. Caches and Proxies . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7.1. Securing HTTP against HTJP . . . . . . . . . . . . . . . 7
7.1.1. Anti-HTJP-Nonce Header . . . . . . . . . . . . . . . 8
7.2. HTJPS . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Hypertext Double Jeopardy Protocol . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
The Hypertext Jeopardy Protocol (HTJP) 1.0 is a stateless application-level response/request protocol that functions as the semantic inverse of the Hypertext Transfer Protocol (HTTP) 1.1 .
超文本危险协议（HTJP）1.0是一种无状态应用程序级响应/请求协议，其功能与超文本传输协议（HTTP）1.1的语义相反。
It can roughly be specified in relation to HTTP by the following rules:
可以通过以下规则大致指定与HTTP相关的内容：
o Where an HTTP client would send an HTTP request message, an HTJP client would send an HTTP response message.
o HTTP客户机将发送HTTP请求消息，而HTJP客户机将发送HTTP响应消息。
o Where an HTTP server would send an HTTP response message, an HTJP server would send an HTTP request message.
o HTTP服务器发送HTTP响应消息时，HTJP服务器将发送HTTP请求消息。
o The HTTP request sent as an HTJP response should be an HTTP request that (if sent to the appropriate HTTP server) would elicit the HTTP response sent in the HTJP request.
o 作为HTJP响应发送的HTTP请求应该是一个HTTP请求（如果发送到适当的HTTP服务器），它将引发HTJP请求中发送的HTTP响应。
HTJP is compatible with the HTTP/1.1 specification, at least in spirit, if not in letter.
HTJP与HTTP/1.1规范兼容，至少在精神上（如果不是文字上）是如此。
HTJP has novel applications in all the following areas:
HTJP在以下所有领域都有新的应用：
o Generative automated testing of HTTP implementations and HTTP-based applications.
o HTTP实现和基于HTTP的应用程序的生成式自动测试。
o Monitoring of HTTP-based applications in production.
o 监视生产中基于HTTP的应用程序。
o Forensic and diagnostic reconstruction of HTTP requests from HTTP response logs.
o 从HTTP响应日志对HTTP请求进行取证和诊断重建。
o Discovery of first-party and third-party security vulnerabilities.
o 发现第一方和第三方安全漏洞。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
It is a little-known fact that HTTP/1.1 already defines itself to be its own inverse mode of operation. Section 3.1 of RFC 7230 [RFC7230], which describes the start line of the HTTP message format, states:
一个鲜为人知的事实是，HTTP/1.1已经将自己定义为自己的反向操作模式。RFC 7230[RFC7230]的第3.1节描述了HTTP消息格式的起始行，其中说明：
In theory, a client could receive requests and a server could receive responses, distinguishing them by their different start-line formats, but, in practice, servers are implemented to only expect a request [...] and clients are implemented to only expect a response.
理论上，客户机可以接收请求，服务器可以接收响应，通过不同的起始行格式区分它们，但在实践中，服务器实现为仅期望请求[…]，而客户机实现为仅期望响应。
It is only convention that HTTP clients send HTTP requests and that HTTP servers send HTTP responses. Therefore, HTJP is just HTTP with some alternative conventions. It is not a distinct protocol. Furthermore, since all messages in HTJP are indistinguishable from HTTP messages, an HTJP peer would have no way of identifying itself explicitly as using HTJP rather than HTTP.
HTTP客户端发送HTTP请求和HTTP服务器发送HTTP响应是唯一的约定。因此，HTJP只是带有一些替代约定的HTTP。它不是一个独特的协议。此外，由于HTJP中的所有消息都与HTTP消息无法区分，因此HTJP对等方无法明确地将自己标识为使用HTJP而不是HTTP。
Therefore, we describe HTJP as a "pseudo-protocol" in order to distinguish clients, servers, and conversations that are using the HTTP conventions laid out in this document from those that use conventions that are more commonly associated with HTTP.
因此，我们将HTJP描述为“伪协议”，以便区分使用本文档中列出的HTTP约定的客户端、服务器和会话与使用更常见的与HTTP关联的约定的客户端、服务器和会话。
An HTJP request MUST be an HTTP response message. An HTJP response message MUST be an HTTP request message that, if issued to the appropriate HTTP server, would elicit the HTTP response specified by the HTJP request being replied to.
HTJP请求必须是HTTP响应消息。HTJP响应消息必须是HTTP请求消息，如果发送到适当的HTTP服务器，将引发由被回复的HTJP请求指定的HTTP响应。
As described in Section 3, HTJP is unconventional but valid HTTP, and so the entirety of the HTTP specification (as defined in [RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235]) MUST be respected when doing so is consistent with HTJP's unique semantics.
如第3节所述，HTJP是非传统但有效的HTTP，因此，当HTTP规范（如[RFC7230]、[RFC7231]、[RFC7232]、[RFC7233]、[RFC7234]和[RFC7235]所定义）与HTJP的独特语义一致时，必须遵守整个HTTP规范。
The following example illustrates a typical message exchange for an HTJP request concerning the same hypothetical server from Section 2.1 of RFC 7230 [RFC7230].
以下示例说明了RFC 7230[RFC7230]第2.1节中关于同一假设服务器的HTJP请求的典型消息交换。
Client request:
客户请求：
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! My payload includes a trailing CRLF.
你好，世界！我的有效载荷包括一个尾部CRLF。
Server response:
服务器响应：
GET /hello.txt HTTP/1.1 Host: www.example.com
GET/hello.txt HTTP/1.1主机：www.example.com
Implementations of HTJP SHOULD respect Postel's Robustness Principle [IAB-PROTOCOL-MAINTENANCE].
HTJP的实现应尊重Postel的健壮性原则[IAB-PROTOCOL-MAINTENANCE]。
Applied to HTJP, Postel's Robustness Principle implies that, given the choice of multiple valid HTJP responses for an HTJP request, one SHOULD prefer a response that is more adherent to the HTTP standard or uses fewer HTTP features. For example, sometimes a User-Agent header has no bearing on the HTTP response from an HTTP server. On seeing such a response in an HTJP request, an HTJP server could validly respond with a practically unlimited number of permutations on the User-Agent header value. However, it SHOULD prefer to respond
应用于HTJP，Postel的健壮性原则意味着，如果一个HTJP请求可以选择多个有效的HTJP响应，那么应该选择更符合HTTP标准或使用更少HTTP特性的响应。例如，有时用户代理头与HTTP服务器的HTTP响应无关。当在HTJP请求中看到这样的响应时，HTJP服务器可以在用户代理头值上使用几乎无限数量的排列有效地响应。然而，它应该更愿意作出回应
with an HTTP request that has no User-Agent header whatsoever, in keeping with Postel's Robustness Principle.
使用没有任何用户代理头的HTTP请求，符合Postel的健壮性原则。
The same consideration applies when encountering an HTJP request for which there are both valid and "pseudo-valid" (Section 4.4) HTJP responses available.
当遇到既有有效又有“伪有效”（第4.4节）HTJP响应的HTJP请求时，同样的考虑也适用。
It may be of interest to a user of HTJP to try issuing an HTJP response as an HTTP request to the appropriate server. This brings up the issue of correctly identifying the host to which the HTJP response should be sent. Much of the time this will be able to be determined from the Host header field of the HTJP response. The Host header is required by conformant HTTP/1.1 requests. In the case that the Host header is not present (for example, if the HTJP response is an HTTP/1.0 request rather than HTTP/1.1), an HTJP response MAY use the absolute URI form in the HTTP request line, to add clarity about the target host if it would be validly accepted by the server. This specific example is complicated by the fact that prior to HTTP/1.1 it was not required that implementations accept the absolute URI form. For this reason, it is also possible to phrase the HTJP response as an HTTP request to a Forward Proxy server, which would have accepted, indeed needed, the absolute URI request line prior to and after HTTP/1.1. As a last resort, it may be possible to heuristically derive the target host of an HTJP response from the HTJP request; for example, the HTJP request may have absolute references to other HTTP resources that seem to come from the same host.
HTJP用户可能会感兴趣，尝试将HTJP响应作为HTTP请求发送到适当的服务器。这就带来了正确识别HTJP响应应该发送到的主机的问题。大多数情况下，这将能够从HTJP响应的主机头字段中确定。一致的HTTP/1.1请求需要主机头。在主机头不存在的情况下（例如，如果HTJP响应是HTTP/1.0请求而不是HTTP/1.1），HTJP响应可以在HTTP请求行中使用绝对URI形式，以增加关于目标主机的清晰性，如果它将被服务器有效地接受。在HTTP/1.1之前，实现不需要接受绝对URI形式，这一事实使这个特定示例变得复杂。出于这个原因，还可以将HTJP响应表述为对转发代理服务器的HTTP请求，转发代理服务器将接受（实际上需要）HTTP/1.1之前和之后的绝对URI请求行。作为最后的手段，可以从HTJP请求试探性地导出HTJP响应的目标主机；例如，HTJP请求可能具有对似乎来自同一主机的其他HTTP资源的绝对引用。
When an HTJP response is issued, there is no guarantee that, by the time the response is received by an HTJP client, the HTTP server that is associated with said response will still reply with it. Providing any guarantee about "when" an HTTP server would reply with said response is obviously a theoretically unsolvable problem and therefore outside the scope of this HTJP specification. It is only required that the HTJP response be correct at some point in the range of the 32-bit Unix Timestamp; see "Seconds Since the Epoch" (Section 4.16) of Unix General Concepts [UNIX-General-Concepts].
当发出HTJP响应时，无法保证在HTJP客户端接收到响应时，与所述响应相关联的HTTP服务器仍将使用该响应进行响应。提供任何关于HTTP服务器“何时”回复所述响应的保证显然是一个理论上无法解决的问题，因此超出了本HTJP规范的范围。只要求HTJP响应在32位Unix时间戳范围内的某个点正确；请参阅Unix通用概念[Unix通用概念]中的“从新纪元开始的秒数”（第4.16节）。
HTJP servers that are responding with an HTTP request for a volatile resource, and with high confidence in the time range at which the resource would be in the state described by the HTJP request, MAY add a Date header to the HTJP response. This is in conformance with the ability for HTTP requests to carry a Date header; see Section 7.1.1.2 of [RFC7231].
使用针对易失性资源的HTTP请求进行响应的HTJP服务器，并且在该资源将处于HTJP请求所描述的状态的时间范围内具有高置信度，可以向HTJP响应添加日期头。这符合HTTP请求携带日期头的能力；见[RFC7231]第7.1.1.2节。
HTJP clients can try to demand more temporal certainty by adding a Date header to their HTTP response, embedding criteria for the time of the HTTP response in the HTTP response itself. Of course, the client might still only receive that exact HTTP response if it manages to deliver the HTTP request at the precise time of the previously requested Date header, and even then it is still not guaranteed due to HTTP caching et cetera.
HTJP客户机可以通过在HTTP响应中添加一个日期头，在HTTP响应本身中嵌入HTTP响应时间的标准，来尝试要求更多的时间确定性。当然，如果客户机能够在先前请求的日期头的准确时间交付HTTP请求，那么它仍然可能只接收到准确的HTTP响应，即使如此，由于HTTP缓存等原因，它仍然无法得到保证。
In the wild, HTTP clients and servers have been known to occasionally exchange HTTP messages that are not conformant to any HTTP specification. For this reason, we will identify a class of messages that are, on the one hand, invalid HTTP messages, yet at the same time, correctly answerable HTJP requests or correct answers to an HTJP request, as "pseudo-valid" HTJP messages.
在野外，HTTP客户机和服务器偶尔会交换不符合任何HTTP规范的HTTP消息。因此，我们将一类消息标识为“伪有效”HTJP消息，这些消息一方面是无效的HTTP消息，但同时又是可正确应答的HTJP请求或对HTJP请求的正确应答。
Consider, for example, an HTTP server that erroneously reports a Content-Length header field of zero when sending an HTTP payload of non-zero length. Despite this HTTP message violating the HTTP specification, it is possible for an HTJP server to receive such a message and correctly respond to it, satisfying the HTJP semantics in doing so.
例如，考虑在发送非零长度的HTTP有效载荷时错误地报告内容长度标题字段为零的HTTP服务器。尽管该HTTP消息违反了HTTP规范，但HTJP服务器仍有可能接收并正确响应该消息，从而满足HTJP语义。
This applies to both HTJP requests and HTJP responses. There may be times when the only valid HTJP response is an invalid HTTP request. When there are both valid and invalid HTTP requests that could satisfy the HTJP request, Postel's Robustness Principle SHOULD be applied, as described in Section 4.1.
这适用于HTJP请求和HTJP响应。有时，唯一有效的HTJP响应可能是无效的HTTP请求。当存在可以满足HTJP请求的有效和无效HTTP请求时，应应用Postel的健壮性原则，如第4.1节所述。
Given that an HTJP response MUST be an HTTP request, and that HTTP requests do not have a status field (such as a status code), there is no way for an HTJP response to signal a failure in response to an HTJP request, via a status code or otherwise. The correct HTJP response to an HTJP request when a server cannot determine an HTTP request that elicits the HTTP response is to not respond at all. The HTJP responder MAY close the connection; however, the HTJP requester MUST NOT interpret the closing of the connection as a response. This can have issues when HTJP servers are hosted behind non-HTJP-aware HTTP proxies, as the proxy may inject a 5xx HTTP response, which could be misinterpreted as an HTJP response. See more on proxies in Section 5.
鉴于HTJP响应必须是HTTP请求，并且HTTP请求没有状态字段（如状态代码），HTJP响应无法通过状态代码或其他方式发出失败信号，以响应HTJP请求。当服务器无法确定引发HTTP响应的HTTP请求时，对HTJP请求的正确HTJP响应是根本不响应。HTJP应答器可关闭连接；但是，HTJP请求者不得将关闭连接解释为响应。当HTJP服务器托管在不支持HTJP的HTTP代理之后时，这可能会出现问题，因为代理可能会注入5xx HTTP响应，这可能会被误解为HTJP响应。有关代理的更多信息，请参见第5节。
Despite being valid HTTP traffic, support for caching and proxying of HTJP traffic is unfortunately not widespread. It is estimated that currently approximately 0.0% of all HTTP-aware intermediaries gracefully handle HTJP traffic. For this reason, it is currently RECOMMENDED that HTJP should not be deployed behind an HTTP proxying or caching layer. Support will likely increase proportionally to HTJP's popularity in production.
尽管是有效的HTTP流量，但遗憾的是，对HTJP流量的缓存和代理的支持并不普遍。据估计，目前大约有0.0%的HTTP感知中介机构能够正常处理HTJP流量。因此，目前建议不要在HTTP代理或缓存层后面部署HTJP。支持可能会随着HTJP在生产中的受欢迎程度成比例增加。
In order that implementations of this specification can operate correctly, and in accordance with [BCP90], the following new HTTP header field would need to be registered in the "Message Headers" registry maintained at <https://www.iana.org/assignments/message-headers/>. To find out the details of this registration, an application should send an HTJP request to a suitable server specifying the Anti-HTJP-Nonce value that the server would have supplied had the IANA registration been made.
为了使本规范的实现能够正确运行，并符合[BCP90]，需要在维护于的“消息头”注册表中注册以下新的HTTP头字段<https://www.iana.org/assignments/message-headers/>. 要了解此注册的详细信息，应用程序应向适当的服务器发送一个HTJP请求，指定如果进行IANA注册，服务器将提供的反HTJP Nonce值。
+-------------------+----------+---------------+---------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+---------------+---------------+
| Anti-HTJP-Nonce | http | informational | Section 7.1.1 |
+-------------------+----------+---------------+---------------+
+-------------------+----------+---------------+---------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+---------------+---------------+
| Anti-HTJP-Nonce | http | informational | Section 7.1.1 |
+-------------------+----------+---------------+---------------+
An incomplete implementation of HTJP is inadvisable from a security perspective. A complete implementation of HTJP may have interesting security features that are worthy of detailed examination. Due to its semantics, the issuing of a successfully authorized HTTP response to an HTJP server will result in a reply containing the HTTP request that elicits said response, including any credentials, tokens, cookies, or other authorization materials that were required to elicit that response.
从安全角度来看，不完整的HTJP实现是不可取的。HTJP的完整实现可能具有值得详细研究的有趣的安全特性。由于其语义，向HTJP服务器发出成功授权的HTTP响应将导致包含引发所述响应的HTTP请求的应答，包括引发该响应所需的任何凭证、令牌、cookie或其他授权材料。
As an example:
例如：
Client request:
客户请求：
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Content-Length: 61
Content-Type: text/plain
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Content-Length: 61
Content-Type: text/plain
Some predictable information accessed using authorization.
使用授权访问某些可预测的信息。
Server response: (line breaks in the Authorization header are for RFC formatting)
服务器响应：（授权标头中的换行符用于RFC格式）
GET /information.txt HTTP/1.1 Host: authorised-usage-service.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiJodGpwIiwibmFtZSI6IkV2ZXJ5b25lIiwiaWF0IjowfQ. JOL-kIObgTI0MzFfm1yVFFkIo1xf7DZGjY_oedRBZW0
GET/information.txt HTTP/1.1主机：authorized-usage-service.example.com授权：载体eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。EYJZWIOIJODGPWIIWIBMFTZSI6IKV2ZXJ5B25LIWIWF0IOWFQ。JOL-KIOBGTI0MZFFM1YFFKIO1XF7DZGJY_oedRBZW0
Given that we cannot prevent anyone from attempting to implement HTJP, it is RECOMMENDED to consider how HTJP impacts security when using HTTP.
由于我们无法阻止任何人试图实现HTJP，因此建议考虑HTTP如何在使用HTTP时影响安全性。
Note that it was only possible to query for the credentialed HTTP request because the response to the authorized request was predictable. HTTP servers could mitigate this vulnerability exposed by HTJP by only serving a response that is at least as secret as the credentials themselves in response to an authorized request.
请注意，只能查询认证的HTTP请求，因为对授权请求的响应是可预测的。HTTP服务器可以通过在响应授权请求时仅提供至少与凭据本身一样机密的响应来缓解HTJP暴露的此漏洞。
A generic solution to this problem is to use an "Anti-HTJP-Nonce" HTTP header in HTTP responses. The value of an "Anti-HTJP-Nonce" header SHOULD be a cryptographically secure random number in any encoding that is valid for an HTTP header value. The length of this number SHOULD be determined by the producer of the HTTP response, accounting for their method of random number generation and their threat model.
此问题的一般解决方案是在HTTP响应中使用“Anti-HTJP Nonce”HTTP头。“Anti-HTJP Nonce”头的值应该是对HTTP头值有效的任何编码中的加密安全随机数。这个数字的长度应该由HTTP响应的生产者决定，考虑他们的随机数生成方法和他们的威胁模型。
HTJP, being just HTTP, has most of the same security concerns and features as HTTP itself. For example, the use of HTJP over an encrypted connection, such as TLS 1.3 [RFC8446], similar to HTTP Secure (HTTPS), is referred to as HTJP Secure (HTJPS). However, it is important to note that, unlike with HTTPS, it is not expected that the hostname you are securely communicating with is the same hostname
作为HTTP，HTJP具有与HTTP本身相同的大部分安全问题和特性。例如，在加密连接（如TLS1.3[RFC8446]）上使用HTJP类似于HTTP安全（HTTPS），称为HTJP安全（HTJPS）。但是，需要注意的是，与HTTPS不同，您安全通信的主机名不应该是相同的主机名
as featured in the Host headers or absolute URIs of the HTJP messages themselves, as HTJP messages are typically referring to other HTTP hosts. This excludes the case of a server that supports both conventional HTTP and HTJP, where it is possible to make HTJP requests securely to the same host that is also the subject of the HTJP requests being made.
正如HTJP消息本身的主机头或绝对URI中所示，因为HTJP消息通常指的是其他HTTP主机。这排除了同时支持传统HTTP和HTJP的服务器的情况，在这种情况下，可以安全地向同一主机发出HTJP请求，该主机也是所发出的HTJP请求的主体。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <https://www.rfc-editor.org/info/rfc7232>.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：有条件请求”，RFC 7232，DOI 10.17487/RFC72322014年6月<https://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <https://www.rfc-editor.org/info/rfc7233>.
[RFC7233]Fielding，R.，Ed.，Lafon，Y.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：范围请求”，RFC 7233，DOI 10.17487/RFC7233，2014年6月<https://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <https://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<https://www.rfc-editor.org/info/rfc7235>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[UNIX-General-Concepts] "General Concepts", Chapter 4 of "The Open Group Base Specifications, Issue 7", 2018 edition, IEEE Std 1003.1-2017, 2018, <http://pubs.opengroup.org/ onlinepubs/9699919799/basedefs/V1_chap04.html>.
[UNIX一般概念]“一般概念”，第4章“开放组基础规范，第7期”，2018版，IEEE Std 1003.1-2017，2018<http://pubs.opengroup.org/ onlinepubs/9699919799/basedefs/V1_chap04.html>。
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004, <https://www.rfc-editor.org/info/bcp90>.
[BCP90]Klyne，G.，Nottingham，M.，和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月<https://www.rfc-editor.org/info/bcp90>.
[IAB-PROTOCOL-MAINTENANCE] Thomson, M., "The Harmful Consequences of the Robustness Principle", Work in Progress, draft-iab-protocol-maintenance-02, March 2019.
[IAB-PROTOCOL-MAINTENANCE]Thomson，M.，“鲁棒性原则的有害后果”，正在进行的工作，草案-IAB-PROTOCOL-MAINTENANCE-022019年3月。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
Also worth mentioning, in case one encounters it in the wild, is the Hypertext Double Jeopardy Protocol (HTJ2P). The Hypertext Double Jeopardy Protocol 1.0 is a stateless application-level request/ response protocol that functions as the inverse of the Hypertext Jeopardy Protocol (HTJP) 1.0 .
同样值得一提的是，如果在野外遇到它，超文本双重危险协议（HTJ2P）。超文本双重危险协议1.0是一种无状态应用程序级请求/响应协议，其功能与超文本危险协议（HTJP）1.0相反。
An HTJ2P response MUST be an HTTP response which would be issued for an HTTP request delivered as the HTJ2P request. Implementations of HTJ2P have groundbreaking potential in the fields of HTTP caching, and in the implementation of HTJP.
HTJ2P响应必须是HTTP响应，该响应将针对作为HTJ2P请求交付的HTTP请求发出。HTJ2P的实现在HTTP缓存和HTJP的实现领域具有开创性的潜力。
Acknowledgements
致谢
The author thanks Alex Trebek for his distinguished contributions to culture and society. The author thanks Peter Phillips for the suggestion of the Anti-HTJP-Nonce header. The author also wishes to thank anyone who has ever built a tool or a technology that made people ask "Why?".
作者感谢Alex Trebek对文化和社会做出的杰出贡献。作者感谢彼得·菲利普斯（Peter Phillips）提出的反HTJP Nonce标题的建议。作者还想感谢任何一位曾经开发过让人们问“为什么”的工具或技术的人。
Author's Address
作者地址
Edmund Fokschaner
埃德蒙·福克申纳
Email: edfokschaner@gmail.com
Email: edfokschaner@gmail.com