RFC 8565
Hypertext Jeopardy Protocol (HTJP/1.0)
Hypertext Jeopardy Protocol (HTJP/1.0) 🎀
okay bestie, title block first 💅 This is RFC 8565, written by E. Fokschaner and dated 1 April 2019 🙈 It's an Independent Submission in the Informational category, with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's just vibing solo ✨
Abstract ✨
so the big idea HTJP flips the usual request/response vibe of HTTP on its head 🔥 With regular HTTP, you connect to a server, ask a question, and hope for a correct answer. With HTJP, you connect to a server, give an answer, and wait for the correct question back 🧠 This document lays out the semantics of 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.
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.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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 . . . . . . . . . . . . . . . . . . . . . . . . 111. Introduction 🌸
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 .
here's how it lines up with HTTP, roughly 🦋
- Where an HTTP client would send an HTTP request message, an HTJP client would send an HTTP response message.
- Where an HTTP server would send an HTTP response message, an HTJP server would send an HTTP request message.
- 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.
HTJP is compatible with the HTTP/1.1 specification, at least in spirit, if not in letter. 🫶
HTJP has novel applications in all the following areas:
- Generative automated testing of HTTP implementations and HTTP-based applications.
- Monitoring of HTTP-based applications in production.
- Forensic and diagnostic reconstruction of HTTP requests from HTTP response logs.
- Discovery of first-party and third-party security vulnerabilities.
2. Conventions Used in This Document 📖
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.
3. Comparison with HTTP 🔍
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:
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's only convention that HTTP clients send HTTP requests and that HTTP servers send HTTP responses 💅 So HTJP is just HTTP with some alternative conventions. It is not a distinct protocol. Also, 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 👀
That's why we describe HTJP as a "pseudo-protocol" 🧚 The label exists to tell apart the clients, servers, and conversations that follow the HTTP conventions laid out in this document from those using the conventions people more commonly associate with HTTP.
4. Response and Request Semantics ✨
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.
As described in Section 3, HTJP is unconventional but valid HTTP, 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. 👑
The following example shows a typical message exchange for an HTJP request about the same hypothetical server from Section 2.1 of RFC 7230 [RFC7230]. Here's the vibe:
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
Hello World! My payload includes a trailing CRLF.Server response:
GET /hello.txt HTTP/1.1
Host: www.example.com4.1. Applicability of Postel's Robustness Principle 🧠
Implementations of HTJP SHOULD respect Postel's Robustness Principle [IAB-PROTOCOL-MAINTENANCE].
so, applied to HTJP, Postel's Robustness Principle means that when there are multiple valid HTJP responses for one HTJP request, one SHOULD prefer a response that sticks closer to the HTTP standard or uses fewer HTTP features. For example, sometimes a User-Agent header has zero bearing on the HTTP response from an HTTP server 💀 When an HTJP request shows up like that, 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 with an HTTP request that has no User-Agent header whatsoever, in keeping with Postel's Robustness Principle. Minimalism is iconic 🤍
The same consideration applies when you run into an HTJP request for which there are both valid and "pseudo-valid" (Section 4.4) HTJP responses available.
4.2. Identifying the Server Associated with an HTJP Response 🗺️
Someone using HTJP might want to try issuing an HTJP response as an HTTP request to the appropriate server. That raises the question of how to correctly identify the host the HTJP response should be sent to. Most of the time, you can figure that out from the Host header field of the HTJP response. The Host header is required by conformant HTTP/1.1 requests.
What if the Host header isn't there? For example, the HTJP response might be an HTTP/1.0 request rather than an HTTP/1.1 one. In that case, an HTJP response MAY use the absolute URI form in the HTTP request line, to add clarity about the target host if the server would validly accept it. This specific example is complicated by the fact that, prior to HTTP/1.1, implementations were not required to accept the absolute URI form. For this reason, it's 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 both before 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. 🕵️♀️
4.3. Temporal Considerations ⏰
real talk, timing is messy 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 associated with that 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 it's 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 servers that respond with an HTTP request for a volatile resource, and that have high confidence in the time range during which the resource would be in the state described by the HTJP request, MAY add a Date header to the HTJP response. This conforms with the ability for HTTP requests to carry a Date header; see Section 7.1.1.2 of [RFC7231].
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. 🥹
4.4. Pseudo-Valid HTJP Messages ✨
okay so bestie, HTTP clients and servers in the wild will sometimes swap HTTP messages that break every HTTP spec out there 💀. We're calling the ones that are technically invalid HTTP but still work as answerable HTJP requests, or correct answers to one, "pseudo-valid" HTJP messages 🎀.
Picture an HTTP server that reports a Content-Length header field of zero while actually sending a payload with a non-zero length 🙈. Yes, that's a spec violation, but an HTJP server can still receive that message, answer it correctly, and satisfy the HTJP semantics while doing it. Iconic behaviour from a messy message 😭.
This applies to both HTJP requests and HTJP responses 🦋. Sometimes the only valid HTJP response is an invalid HTTP request, and that's just how it goes sometimes 💅. 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 🌸.
4.5. HTTP Responses That Are Not Requestable
so here's the tea 🫖. An HTJP response MUST be an HTTP request, and HTTP requests don't have a status field (like a status code) 😬. That means there's no way for an HTJP response to signal a failure in response to an HTJP request, not via a status code or any other way 💀.
So what's the correct move when a server can't work out which HTTP request would produce the HTTP response it's looking for? Honestly, it's giving "don't respond at all" 🙈. The HTJP responder MAY close the connection, but the HTJP requester MUST NOT interpret the closing of the connection as a response 🫶. Lowkey messy, I know 😭.
This can get chaotic when HTJP servers are hosted behind non-HTJP-aware HTTP proxies 🧚. The proxy might inject a 5xx HTTP response, which could be misread as an HTJP response. See more on proxies in Section 5 🔥.
5. Caches and Proxies
bestie, caching and proxying HTJP traffic is valid HTTP traffic, but support for it is honestly not widespread 😭. It's estimated that approximately 0.0% of all HTTP-aware intermediaries gracefully handle HTJP traffic 💀. So for now, it is RECOMMENDED that HTJP should not be deployed behind an HTTP proxying or caching layer 🌈. Support will likely go up in proportion to HTJP's popularity in production, so keep an eye on it ✨.
6. IANA Considerations
so to keep implementations of this spec working correctly, and following [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 🔍.
+-------------------+----------+---------------+---------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+---------------+---------------+
| Anti-HTJP-Nonce | http | informational | Section 7.1.1 |
+-------------------+----------+---------------+---------------+7. Security Considerations 🚨
this section is serious business, bestie, so pay attention 👑.
7.1. Securing HTTP against HTJP
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 🔍. Here's the scary bit: because of its semantics, when a successfully authorized HTTP response gets issued to an HTJP server, the result is a reply containing the HTTP request that elicited that response, including any credentials, tokens, cookies, or other authorization materials that were needed to get it 😱.
Let's look at 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
Some predictable information accessed using authorization.Server response: (line breaks in the Authorization header are for RFC formatting)
GET /information.txt HTTP/1.1
Host: authorised-usage-service.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiJodGpwIiwibmFtZSI6IkV2ZXJ5b25lIiwiaWF0IjowfQ.
JOL-kIObgTI0MzFfm1yVFFkIo1xf7DZGjY_oedRBZW0Given that we cannot stop anyone from trying to implement HTJP, it is RECOMMENDED to consider how HTJP impacts security when using 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 🔐.
7.1.1. Anti-HTJP-Nonce Header
the generic fix for 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 🧚.
7.2. HTJPS
HTJP is just HTTP, so it has most of the same security concerns and features as HTTP itself 💜. For example, using HTJP over an encrypted connection, such as TLS 1.3 [RFC8446], similar to HTTP Secure (HTTPS), is referred to as HTJP Secure (HTJPS) 🔒. But here's the plot twist: unlike with HTTPS, it is not expected that the hostname you're securely talking to is the same as the hostname in the Host headers or absolute URIs of the HTJP messages themselves 😱. That's because HTJP messages are typically referring to other HTTP hosts 🌸. The exception is a server that supports both conventional HTTP and HTJP, where it's possible to make HTJP requests securely to the same host that is also the subject of those HTJP requests 💖.
8. References
8.1. Normative References
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.8.2. Informative References
[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>.
[IAB-PROTOCOL-MAINTENANCE]
Thomson, M., "The Harmful Consequences of the Robustness
Principle", Work in Progress, draft-iab-protocol-
maintenance-02, March 2019.
[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>.Appendix A. Hypertext Double Jeopardy Protocol 🎲
also worth knowing, in case you spot 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 works as the inverse of the Hypertext Jeopardy Protocol (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 🌈✨.
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?" 😭🦋.
Author's Address 💌
Edmund Fokschaner
Email: edfokschaner@gmail.com
📦 where this page comes from
- ietf: rfc8565 2019-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms