bug: MAX_BODY_SIZE ignored for `/bytes` and `/stream-bytes`

[derekmpage]

https://github.com/mccutchen/go-httpbin/blob/1b709ccb71218a182c1be8d9b853119fa41a4c1f/httpbin/handlers.go#L924C5-L924C14

Is it intentional to hardcode the max bytes in handleBytes function? Rather then honor MAX_BODY_SIZE?

            patch: |
              - op: add
                path: /spec/template/spec/containers/0/env
                value:
                  - name: MAX_BODY_SIZE
                    value: "10485760"
                  - name: SRV_MAX_HEADER_BYTES
                    value: "65536"

curl -v http://localhost:18080/bytes/10485760 -o bigfile
ls -lh bigfile
* Host localhost:18080 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying [::1]:18080...
* Connected to localhost (::1) port 18080
> GET /bytes/10485760 HTTP/1.1
> Host: localhost:18080
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Origin: *
< Content-Type: application/octet-stream
< Date: Mon, 05 Jan 2026 21:07:31 GMT
< Transfer-Encoding: chunked
<
{ [3900 bytes data]
100  100k    0  100k    0     0   566k      0 --:--:-- --:--:-- --:--:--  568k
* Connection #0 to host localhost left intact

-rw-r--r-- 1 user user 100K Jan  5 16:07 bigfile

[mccutchen]

Ha, no, I do not think that was intentional. I think it was brought over in the initial re-implementation of the Python code and never updated to impose a limit. Thanks for the report!

[derekmpage]

Cool, I don't mind submitting a PR.