Change:
information that does not reveal information about the encapsulated response. <ins> An Oblivious Gateway Resource that does not receive a response can itself generate a response with an appropriate error status code (such as 504 (Gateway Timeout); see HTTP), which is then encapsulated in the same way as a successful response. </ins> In order to achieve the privacy and security goals of the protocol an Oblivious Gateway Resource also needs to observe the guidance in server-responsibilities.

Discussion:
Pretty much what you might expect; see Section 7.6 of [HTTP]. NAME WDYT?
The draft says An Oblivious Gateway Resource, if it receives any response from the Target Resource, sends a single 200 response containing the encapsulated response. What happens if that encapsulated response is zero-length? The section seems ambiguous on this point. To encapsulate a response the gateway resource needs to hold the private hpke key for every endpoint it services, even if that response is a simple status code with no body content, as is common with POST requests. For security, it would be nice if it were possible to restrict the private key to an offline process. That is, instead of the gateway performing decapsulation itself, it writes the encapsulated request directly to the target and returns success unconditionally. Then a separate process, running in a more restricted environment, performs decapsulation and analysis of the client requests. The attack surface is reduced, and vulnerabilities in the gateway implementation are less serious because it cannot leak the keys. One way to do this is to have the gateway return to the relay with no response body, and have the relay forward that back to the client. The client would have to assume success in this case. For some applications, this "best effort" submission could be an acceptable trade off for better data path integrity.
The Encapsulated Response encoding currently does not admit a zero-length (empty) response. It includes at least max(Nn, Nk)+Nt (ciphertext tag size) bytes. This is an interesting use case. I can imagine changing the Encapsulated Response type to admit successful zero-length responses to signal "I received your request and will process it later." This isn't authenticated any differently from non-2xx responses from the gateway, so I don't think it's a problem that the HPKE context is not used to generate the response here. I suppose the main question (to me) is whether or not clients should be configured to expect this behavior. What happens if a client gets an empty 200 response when it expected a non-empty response? Should it retry? Should it only accept this if the client is configured this way? The latter is probably doable. NAME NAME thoughts?

I could see allowing it the client has a configuration to handle it specially, but in general, I think that a client wouldn't expect an empty response that is still a 200, since it doesn't have any expected content type, etc.
The encapsulated request and response is effectively just HTTP. IIUC this is a proposal to change the HTTP interaction model to fire-and-forget. I.e. infer that when something on the path claims it delivered something, the client should accept that. Why do we want to change HTTP? A way to emulate this, without changing HTTP semantics, is to have the Gateway synthesize an encapsulated response itself. Then the client doesn't need to handle an empty response. If you cared for signalling, the Gateway could include a field in the synthesized response that indicted this had happened.
Agreed with Lucas on this
The use case is to hide the private key from the Gateway. Is this possible without access to the key?
NAME I don't think this is a change to HTTP at all. It's just a change to the HTTP usage here. It is totally feasible for the relay to return a 200 response to the client that means "I accepted your relay request and will forward it later." This seems totally valid and indeed something we might want for applications that don't need a response to the client and want the relay to do some sort of batching. If we wanted to support this, maybe we could use a separate content type for the response that is along the lines of an acknowledgement, rather than a response with actual content.
That's fair. But then we should not be overloading the OHTTP interaction model. Rather, when the Gateway responds with a 200, it always contains an enclosed response as today. And if you want a different interaction, then return a different status code like : This 202 representation is not the enclosed request - it could be empty.
Oh, perfect! I didn't know 202 existed. That sounds like it would work here without any sort of change, beyond maybe a note saying that it's possible to use?
Personally I'd lean more towards being explicit that this could happen, and is effectively a conditional terminal branch of the sequence at step 6 https://ietf-wg-URL But that's just my 2c
Being explicit makes it more likely this path will be implemented uniformly.

Specifying the operation of the protocol for a 202 is possible, but I doubt we could do that trivially. A relay can send 202. This introduces some interesting consequences for end-to-end reliability. A gateway might also send 202 (it takes the request, stores it, responds). The gateway concerns are approximately the same. As NAME observes, this might allow the gateway to operate without the private key, which is a very useful feature for something like STAR. If we deal with this case in this document, we'll have to cover all bases. I see three options: We specify the necessary behaviour here, in full. We describe the general sort of circumstance in which it might be advantageous to have the client not wait around for a full end-to-end response. We explain that the relay/gateway needs to understand the application for which it is forwarding requests and that 202 responses are generally not acceptable. We explain that by responding with 202 the relay/gateway takes responsibility for the forwarding of the request and any necessary actions that might be needed to improve reliability, including retries. We explain that clients that use such a relay/gateway need to be aware of what the relay/gateway might do and that this means that they will not get any end-to-end signal that provides them with a reliable indication that their request was processed. We specify a separate extension, with all of the above. We leave this extension to each application of the protocol, which can address each of the above points as it chooses. That application can do less about addressing those concerns as it might specify the use of 202 at only one of the nodes. I'm guessing that this is for STAR, so it does make a degree of sense to have the gateway to store requests and respond with 202. As a telemetry system, the loss of reliability is essentially zero (you don't get an end-to-end confirmation that the key you chose worked, so it's not perfect, but that's deliberate and more of a feature than a bug in that case). So I'm inclined to suggest that STAR deal with describing this.
Yeah, my concern is that this could be feature creep and delay this document further, when it's already achieved the starting goals. Punting to another document seems fair to me. What I might expect here is some brief service about how a gateway responds when there is no response from the target.

This thread started with the draft excerpt: Ignoring fancy usecases, there are failure cases for the the Gateway: fail to resolve the target, or fail to connect to it, or fail receive a complete response. In other HTTP intermediation, returning a 5xx (e.g. 502, 504) is common for such cases. If the gateway did that here, I'm not clear what expectations there on the response - the MUST requirement for the 200 case can't apply right?
The MUST there is implicitly conditional on the gateway receiving a response. We can add a sentence saying that if the gateway doesn't receive a response it can encapsulate an appropriate error response (like 504).
I've opened . It doesn't address this specific concern, but it will deal with the problem Lucas identified.
I threw together describing an unreliable variant of OHTTP that satisfies the use case motivating this issue. NAME (and others), please have a look! Contributions from everyone are welcome.
The unreliable-ohttp draft addresses my motivating use case, and there's at least some clarifying text about error handling for the Relay, so I'm satisfied this is addressed.