[GH-ISSUE #931] Cannot upload a file larger than 2.5 MB #657

New issue

Closed

opened 2026-02-25 23:43:11 +03:00 by kerem · 1 comment

kerem commented

2026-02-25 23:43:11 +03:00

Owner

Originally created by @mmomjian on GitHub (Dec 22, 2023).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/931

I am running healthchecks.io in a docker container. PING_BODY_LIMIT does not seem to allow the uploading of any files larger than 2.5 MB.

The smaller files do get uploaded to S3, and appear in the list of pings. The larger files that error out never appear as a ping. I tried disabling S3 and I still get a hard cap at around 2.5 MB. Please let me know what logs or information could be helpful to figuring out this issue.

Steps to reproduce:
Run healthchecks.io in a docker container.

docker compose.yaml

  healthchecks:
    container_name: healthchecks
    restart: unless-stopped
    image: healthchecks/healthchecks:latest
    environment:
      REGISTRATION_OPEN: 'False'
      PING_BODY_LIMIT: 'None'
      # I also tried '50000000'
      S3_BUCKET: ${s3bucket}
      S3_ENDPOINT: ${s3endpoint}
      S3_ACCESS_KEY: ${s3accesskey}
      S3_SECRET_KEY: ${s3privatekey}
      S3_REGION: ${s3region}
      S3_TIMEOUT: 60
      ALLOWED_HOSTS: '*'
      DB: sqlite
      DB_NAME: /data/hc.sqlite
      DEBUG: 'True'
      DEFAULT_FROM_EMAIL: "${smtppre}+healthchecks@${smtppost}"
      EMAIL_HOST: ${smtphost}
      EMAIL_HOST_PASSWORD: ${smtppw}
      EMAIL_HOST_USER: ${smtpuser}
      EMAIL_PORT: ${smtpport}
      EMAIL_USE_TLS: 'True'

Create two dummy files of 2.5 and 2.7 MB, and try to attach each one as a log


# docker exec -it healthchecks sh

$ /dlib/curl --version
curl 8.5.0 (aarch64-unknown-linux-musl) libcurl/8.5.0 OpenSSL/1.1.1t zlib/1.2.12 libssh2/1.9.0 nghttp2/1.43.0
Release-Date: 2023-12-06
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM SSL threadsafe TLS-SRP UnixSockets

$ tr -dc "A-Za-z 0-9" < /dev/urandom | fold -w100|head -n 25000 > big2.5.txt
/dlib/curl -X POST -v -fsS -m 10 --data-binary @big2.5.txt http://127.0.0.1:8000/ping/<red>/<red>/0

*   Trying 127.0.0.1:8000...
* Connected to 127.0.0.1 (127.0.0.1) port 8000
> POST /ping/<red>/<red>/0 HTTP/1.1
> Host: 127.0.0.1:8000
> User-Agent: curl/8.5.0
> Accept: */*
> Content-Length: 2525000
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
>
* Done waiting for 100-continue
* We are completely uploaded and fine
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Access-Control-Allow-Origin: *
< Expires: Fri, 22 Dec 2023 00:30:19 GMT
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate, private
< X-Frame-Options: DENY
< Content-Length: 2
< Vary: Cookie
< X-Content-Type-Options: nosniff
< Referrer-Policy: same-origin
< Cross-Origin-Opener-Policy: same-origin
<
* Connection #0 to host 127.0.0.1 left intact
OK$




tr -dc "A-Za-z 0-9" < /dev/urandom | fold -w100|head -n 27000 > big2.7.txt
/dlib/curl -X POST -v -fsS -m 10 --data-binary @big2.7.txt http://127.0.0.1:8000/ping/<red>/<red>/0

*   Trying 127.0.0.1:8000...
* Connected to 127.0.0.1 (127.0.0.1) port 8000
> POST /ping/<red>/<red>/0 HTTP/1.1
> Host: 127.0.0.1:8000
> User-Agent: curl/8.5.0
> Accept: */*
> Content-Length: 2727000
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
>
* Done waiting for 100-continue
* We are completely uploaded and fine
< HTTP/1.1 400 Bad Request
< Content-Type: text/html; charset=utf-8
< Vary: Accept-Encoding, Cookie
< X-Frame-Options: DENY
< Content-Length: 91537
< X-Content-Type-Options: nosniff
< Referrer-Policy: same-origin
< Cross-Origin-Opener-Policy: same-origin
* The requested URL returned error: 400
* Closing connection
curl: (22) The requested URL returned error: 400
$

$ du -h big2*
2.5M    big2.5.txt
2.7M    big2.7.txt

Originally created by @mmomjian on GitHub (Dec 22, 2023). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/931 I am running healthchecks.io in a docker container. PING_BODY_LIMIT does not seem to allow the uploading of any files larger than 2.5 MB. The smaller files do get uploaded to S3, and appear in the list of pings. The larger files that error out never appear as a ping. I tried disabling S3 and I still get a hard cap at around 2.5 MB. Please let me know what logs or information could be helpful to figuring out this issue. Steps to reproduce: Run healthchecks.io in a docker container. docker compose.yaml ``` healthchecks: container_name: healthchecks restart: unless-stopped image: healthchecks/healthchecks:latest environment: REGISTRATION_OPEN: 'False' PING_BODY_LIMIT: 'None' # I also tried '50000000' S3_BUCKET: ${s3bucket} S3_ENDPOINT: ${s3endpoint} S3_ACCESS_KEY: ${s3accesskey} S3_SECRET_KEY: ${s3privatekey} S3_REGION: ${s3region} S3_TIMEOUT: 60 ALLOWED_HOSTS: '*' DB: sqlite DB_NAME: /data/hc.sqlite DEBUG: 'True' DEFAULT_FROM_EMAIL: "${smtppre}+healthchecks@${smtppost}" EMAIL_HOST: ${smtphost} EMAIL_HOST_PASSWORD: ${smtppw} EMAIL_HOST_USER: ${smtpuser} EMAIL_PORT: ${smtpport} EMAIL_USE_TLS: 'True' ``` Create two dummy files of 2.5 and 2.7 MB, and try to attach each one as a log ``` # docker exec -it healthchecks sh $ /dlib/curl --version curl 8.5.0 (aarch64-unknown-linux-musl) libcurl/8.5.0 OpenSSL/1.1.1t zlib/1.2.12 libssh2/1.9.0 nghttp2/1.43.0 Release-Date: 2023-12-06 Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM SSL threadsafe TLS-SRP UnixSockets $ tr -dc "A-Za-z 0-9" < /dev/urandom | fold -w100|head -n 25000 > big2.5.txt /dlib/curl -X POST -v -fsS -m 10 --data-binary @big2.5.txt http://127.0.0.1:8000/ping/<red>/<red>/0 * Trying 127.0.0.1:8000... * Connected to 127.0.0.1 (127.0.0.1) port 8000 > POST /ping/<red>/<red>/0 HTTP/1.1 > Host: 127.0.0.1:8000 > User-Agent: curl/8.5.0 > Accept: */* > Content-Length: 2525000 > Content-Type: application/x-www-form-urlencoded > Expect: 100-continue > * Done waiting for 100-continue * We are completely uploaded and fine < HTTP/1.1 200 OK < Content-Type: text/html; charset=utf-8 < Access-Control-Allow-Origin: * < Expires: Fri, 22 Dec 2023 00:30:19 GMT < Cache-Control: max-age=0, no-cache, no-store, must-revalidate, private < X-Frame-Options: DENY < Content-Length: 2 < Vary: Cookie < X-Content-Type-Options: nosniff < Referrer-Policy: same-origin < Cross-Origin-Opener-Policy: same-origin < * Connection #0 to host 127.0.0.1 left intact OK$ tr -dc "A-Za-z 0-9" < /dev/urandom | fold -w100|head -n 27000 > big2.7.txt /dlib/curl -X POST -v -fsS -m 10 --data-binary @big2.7.txt http://127.0.0.1:8000/ping/<red>/<red>/0 * Trying 127.0.0.1:8000... * Connected to 127.0.0.1 (127.0.0.1) port 8000 > POST /ping/<red>/<red>/0 HTTP/1.1 > Host: 127.0.0.1:8000 > User-Agent: curl/8.5.0 > Accept: */* > Content-Length: 2727000 > Content-Type: application/x-www-form-urlencoded > Expect: 100-continue > * Done waiting for 100-continue * We are completely uploaded and fine < HTTP/1.1 400 Bad Request < Content-Type: text/html; charset=utf-8 < Vary: Accept-Encoding, Cookie < X-Frame-Options: DENY < Content-Length: 91537 < X-Content-Type-Options: nosniff < Referrer-Policy: same-origin < Cross-Origin-Opener-Policy: same-origin * The requested URL returned error: 400 * Closing connection curl: (22) The requested URL returned error: 400 $ $ du -h big2* 2.5M big2.5.txt 2.7M big2.7.txt ```

kerem closed this issue

2026-02-25 23:43:11 +03:00

kerem commented

2026-02-25 23:43:11 +03:00

Author

Owner

@cuu508 commented on GitHub (Dec 22, 2023):

Thanks for the report and the thorough investigation.

When I tried to reproduce the issue, I got this error report in email:

[Django] ERROR (EXTERNAL IP): Request body exceeded settings.DATA_UPLOAD_MAX_MEMORY_SIZE.

And, indeed, the default value for DATA_UPLOAD_MAX_MEMORY_SIZE is 2.5MB

https://docs.djangoproject.com/en/5.0/ref/settings/#data-upload-max-memory-size

Rather than exposing another setting as an env variable, I'm thinking perhaps in settings.py we could do

DATA_UPLOAD_MAX_MEMORY_SIZE = max(PING_BODY_LIMIT, 2621440)

@cuu508 commented on GitHub (Dec 22, 2023): Thanks for the report and the thorough investigation. When I tried to reproduce the issue, I got this error report in email: > [Django] ERROR (EXTERNAL IP): Request body exceeded settings.DATA_UPLOAD_MAX_MEMORY_SIZE. And, indeed, the default value for DATA_UPLOAD_MAX_MEMORY_SIZE is 2.5MB https://docs.djangoproject.com/en/5.0/ref/settings/#data-upload-max-memory-size Rather than exposing another setting as an env variable, I'm thinking perhaps in settings.py we could do ``` DATA_UPLOAD_MAX_MEMORY_SIZE = max(PING_BODY_LIMIT, 2621440) ```