Why does boulder/pebble require content-length on POST?

Client dev
1

Hi folks,

I'm working on a new ACME client that internally uses a streaming API for generating JWS bodies for POST requests. So I enabled chunked transfer encoding in the HTTP client, but I get a 400 response from pebble with the body:

{
   "type": "urn:ietf:params:acme:error:malformed",
   "detail": "missing Content-Length header on POST",
   "status": 400
}

I think this boulder PR introduced the requirement, and this issue mentions that it was to emulate a behavior in Akamai in local development. I'm not turning up anything in the Akamai docs about what the check is doing or why it's there (zip bomb prevention?), and the response from both staging & production seems to be coming from boulder since the response is an application/problem+json and there is a ContentLengthRequired prom counter. RFC8555 doesn't mention anything about the transfer-encoding or content-length requirements.

Can you please shed some light on why chunked request bodies are not allowed?

2 Likes
2

Welcome to the Let's Encrypt Community! :slightly_smiling_face:

Just adding some resources to further discussion.

3

I'm honestly not sure! Especially since we're requiring the presence of a Content-Length header, but not rejecting requests whose header indicates that they are too large, nor rejecting requests whose length doesn't match what the header says.

6 Likes
4

ok, any chance you confirm that there's no Akamai rule intercepting these requests? If it's no longer there then check shouldn't be needed for dev/prod parity.

And if that's the case, would you accept a boulder/pebble PR to drop this check? I'm thinking that the request body could wire up a LimitReader instead.

5

We no longer have a CDN in front of our API, so it’s just our HTTP stack now.

5 Likes
6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.