Consider Prefer: respond-async

[martinthomson]

The current design uses a new media type (which appears to be zero-length always, I couldn't see where the content was defined).

An alternative is this: Prefer: respond-async, which allows a client to indicate that it might prefer a 202 status response rather than a full answer to its request.

[rillian]

Interesting. I guess this would look like the client sending:

POST / HTTP/1.1
Host: ohttp.example.com
Content-Type: message/ohttp-req
Prefer: respond-async
Content-Length: 559

<encapsulated bhttp request>

The Relay or Gateway would choose to respond either by queuing the request for later processing and returning:

HTTP/1.1 202 Accepted
Content-Length: 0

<empty body>

or by forwarding and returning as in reliable ohttp:

HTTP/1.1 200 OK
Content-Type: message/bhttp-res
Content-Length: 153

<encapsulated bhttp response>

Quite similar except for the empty Content-Type header on the zero-length unreliable response body. This leaves the decision up to the servers rather than the client like the Accept: message/ohttp-ack method.

Pros

• Reuses an existing mechanism
• Servers ultimately choose delivery method
• wait parameter allows clients to give a delivery-delay hint

Cons

• More complicated semantics, see e.g. #8
• The Accept mechanism is documented in the base HTTP Semantics spec while Prefer header is described by a separate rfc and may not be as well-known.

[martinthomson]

Practically speaking, Accept only gives a suggestion that a server can ignore, so I think that the two are functionally equivalent.

I don't see any value in the wait parameter in this case, unless the processing at the gateway is likely to take a very long time (and then you have to deal with the potential that the value is ignored anyway).