Shall we trust content length for RequestBodyLimitAction?

[jcchavezs]

Currently we record the body per chunks as it is coming and when reach the limit we decide to trigger the RequestBodyLimitAction. As buffering is expensive, in specific cases like Envoy it is worth to investigate if we should trust content-length header for rushing this decision even before the buffering.

[anuraaga]

Sending a content length but not sending a payload of the same size is invalid http. So I think it's fine to read it for eager limit checking given even if it wasn't accurate the request would be rejected.

[M4tteoP]

we should trust content-length header for rushing this decision even before the buffering

I see value in doing this if the LimitAction is deny, but it requires an extra API method that accepts the content length, checks the LimitAction, and directly rises an interruption if it is above the limit, doesn't it?

[anuraaga]

Phase 1 should have content length from headers so don't think it needs an extra API. Meaning this should be for eagerly checking in phase 1 what would otherwise happen within phase 2.