Allow for `Incremental: ?0`

[thibmeu]

In its current state, the draft only allows one value: ?1. This means there are two states:

• No header, and the server uses its default
• Incremental: ?1 and the server allows incremental request/response

I think the state Incremental: ?0 should be mentioned, and allowed. For instance, OHTTP has privacy concerns with incremental/chunked response. These concerns go away when the request and responses are buffered. Client should be able to inform the server they would like to use this mode.

Similar to Incremental: ?1, the server could perfectly ignore this header, or return they don't support it.

[kazuho]

Thank you for raising the point.

I do not understand the security aspects of OHTTP and I could be wrong, but could you clarify why it is preferable to have a network signal rather than relying on local decision (i.e., server itself can wait for the entire request, then send the entire response at once)?

[thibmeu]

Incremental being broader than OHTTP, there could be other use cases that require buffering down the line.

For your question on OHTTP specifically, my understanding is as follow:

OHTTP initial figure highlights the relay sends the request to the gateway, and waits for its response before replying to the client.
RFC 9458 Section 6.2.3 discusses how an attacker can do traffic analysis. One mitigation is for Relay to add delay.

For chunked OHTTP, this would also include buffering client request/gateway response. By buffering the entire request before sending the entire response, the relay prevents an attacker from being able to fingerprint a client by granularily sending packets (time, size, others).
This interactivity privacy consideration is highlighted in the draft for chunked OHTTP.