tfpauly
commented
1 year ago I wonder if this needs to be explicitly addressed? If we look at OHTTP without chunking, there is no max size (other than the number of bytes that can be in the outer stream/body. If we view chunking as a way to allow incremental processing of something that otherwise would be one larger OHTTP message, it will always be strictly less memory than it would have been otherwise.
It is a good point that a particular chunk size could fingerprint a client if it was very consistent; similarly, the chunk size could reveal information to the relay about the contents (although the overall message size can too).
Varints for lengths have this problem where they can be very large, requiring a lot of memory. Even TLS has this problem and it only has 16k chunks. It would be good to have some way to negotiate chunk size. This ends up being a little weird though.
If you have too many size options, that leaks client details in a way that might be identifying.
If you negotiate on the outside of the encapsulation, the relay has to know to forward it. If you negotiate on the inside, it might end up going to the target and not the gateway.
That is, this is much like #5: we will need to be careful.