github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-07 12:37:14 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

File uploads/attachments fail at 32MB despite 500MB configuration #2344

New Issue
Closed
opened 2026-03-22 14:03:48 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-03-22 14:03:48 -05:00
Owner
Copy Link

Originally created by @jeroenmarchand on GitHub (Sep 12, 2025).

Description

Vikunja Version

v1.0.0-rc2
image: vikunja/vikunja:unstable
sha256:510cc702dfc385ed56295d4824648cd6f4b44b6095b266ce1aa7b1f62b6428d4

Browser and version

N/A (affects web interface but also reproducible via API)

OS and version

Docker (Linux containers)

What is the expected behaviour?

Files should upload successfully up to the configured 500MB limit as indicated by the /api/v1/info endpoint.

What is the actual behaviour?

File uploads fail with HTTP 400 Bad Request for files larger than exactly 33,554,432 bytes (32MB), despite Vikunja showing a 500MB limit.

Steps to reproduce the behaviour

  1. Configure Vikunja with VIKUNJA_FILES_MAXSIZE: 500MB
  2. Verify /api/v1/info endpoint shows "max_file_size": "500MB"
  3. Create test files: 
    # Exactly 32MB (works)
dd if=/dev/zero of=test-32MB.pdf bs=1048576 count=32
# 32.5MB (fails)  
dd if=/dev/zero of=test-32.5MB.pdf bs=1024 count=33280
  4. Upload both files via web interface:
    • test-32MB.pdf (33,554,432 bytes) → Works
    • test-32.5MB.pdf (34,078,720 bytes) → Does not work

Additional information

  • Exact boundary: Files ≤ 33,554,432 bytes work, files > 33,554,432 bytes fail
  • 32MB significance: 33,554,432 equals 32 << 20 (common default for HTTP parsing)
  • No reverse proxy: Direct access to Vikunja
  • Configuration verified: /api/v1/info correctly shows 500MB limit

This suggests the issue may be related to HTTP framework multipart parsing limits that need to be aligned with Vikunja's configured file size limit.

Vikunja Version

v1.0.0-rc2

Browser and version

N/A (affects web interface but also reproducible via API)

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

Originally created by @jeroenmarchand on GitHub (Sep 12, 2025). ### Description ## Vikunja Version `v1.0.0-rc2` image: vikunja/vikunja:unstable sha256:510cc702dfc385ed56295d4824648cd6f4b44b6095b266ce1aa7b1f62b6428d4 ## Browser and version N/A (affects web interface but also reproducible via API) ## OS and version Docker (Linux containers) ## What is the expected behaviour? Files should upload successfully up to the configured 500MB limit as indicated by the `/api/v1/info` endpoint. ## What is the actual behaviour? File uploads fail with **HTTP 400 Bad Request** for files larger than exactly **33,554,432 bytes** (32MB), despite Vikunja showing a 500MB limit. ## Steps to reproduce the behaviour 1. Configure Vikunja with `VIKUNJA_FILES_MAXSIZE: 500MB` 2. Verify `/api/v1/info` endpoint shows `"max_file_size": "500MB"` 3. Create test files: ```bash # Exactly 32MB (works) dd if=/dev/zero of=test-32MB.pdf bs=1048576 count=32 # 32.5MB (fails) dd if=/dev/zero of=test-32.5MB.pdf bs=1024 count=33280 ``` 4. Upload both files via web interface: - `test-32MB.pdf` (33,554,432 bytes) → Works - `test-32.5MB.pdf` (34,078,720 bytes) → Does not work ## Additional information - **Exact boundary**: Files ≤ 33,554,432 bytes work, files > 33,554,432 bytes fail - **32MB significance**: 33,554,432 equals `32 << 20` (common default for HTTP parsing) - **No reverse proxy**: Direct access to Vikunja - **Configuration verified**: `/api/v1/info` correctly shows 500MB limit This suggests the issue may be related to HTTP framework multipart parsing limits that need to be aligned with Vikunja's configured file size limit. ### Vikunja Version v1.0.0-rc2 ### Browser and version N/A (affects web interface but also reproducible via API) ### Can you reproduce the bug on the Vikunja demo site? No ### Screenshots _No response_
GiteaMirror commented 2026-03-22 14:03:49 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Sep 30, 2025):

Will be fixed by https://github.com/go-vikunja/vikunja/pull/1577

@kolaente commented on GitHub (Sep 30, 2025): Will be fixed by https://github.com/go-vikunja/vikunja/pull/1577
GiteaMirror commented 2026-03-22 14:03:49 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Sep 30, 2025):

Please check with the next unstable build (should be ready for deployment in ~30min, also on try).

@kolaente commented on GitHub (Sep 30, 2025): Please check with the next unstable build (should be ready for deployment in ~30min, also on [try](https://try.vikunja.io)).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#2344
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?