[modules | media] Fix media upload error handling for non-JSON server responses#10700
Merged
driusan merged 2 commits intoJun 30, 2026
Conversation
The media upload flow assumed every error response was JSON and attempted to parse the response unconditionally. When nginx rejected oversized uploads with an HTML 413 response, the browser threw an Unexpected token '<' exception and the upload error handling failed. This change wraps JSON parsing in defensive try/catch handling so HTML or other non-JSON responses fall back to the default error message instead of crashing the frontend.
priyavrat7
added
Category: Bug
skarya22
approved these changes
Jun 30, 2026
skarya22
left a comment
skarya22
left a comment
Contributor
There was a problem hiding this comment.
LGTM! I tried to upload a 3G file on Chrome on 29.0-release and it froze, but when I switched to this branch and re-compiled I got a File Too Large error. The problem was not present on Firefox.
skarya22
added
the
Passed manual tests
driusan
reviewed
Jun 30, 2026
| try { | ||
| msg = JSON.parse(xhr.response).message; | ||
| } catch (e) { | ||
| // Ignore non-JSON responses. |
Collaborator
There was a problem hiding this comment.
should we console.warn the error if it's not?
Author
There was a problem hiding this comment.
Hello @driusan, the msg was already initialized at line 346, so ideally we do not need to do anything inside catch block. But if you suggest we can do something like this console.warn('Upload response was not valid JSON.'); for developers
Collaborator
There was a problem hiding this comment.
I meant something like:
console.warn('Failed upload response was not valid JSON', e);
so that the error isn't lost silently in case it was significant. The try / catch is catching all errors.
kongtiaowang
pushed a commit
to kongtiaowang/Loris
that referenced
this pull request
Jul 2, 2026
… responses (aces#10700) Uploading a file larger than the configured limit in the LORIS Media module caused the browser to freeze and show JavaScript stack traces. The initial assumption was that the backend was failing, but the actual failure mode was in the frontend response handling. The frontend should not freeze or crash when the server returns HTML instead of JSON. Oversized uploads now fall back to the default error message. Fixes aces#10659
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
closes #10659
Situation
Uploading a file larger than the configured limit in the LORIS Media module caused the browser to freeze and show JavaScript stack traces. The initial assumption was that the backend was failing, but the actual failure mode was in the frontend response handling.
Task
Identify the root cause of the upload failure, verify it against the nginx-based VM behavior, and update the upload flow so it can safely handle non-JSON error responses.
Action
I reproduced the issue on the test VM, confirmed that oversized uploads were rejected by nginx with an HTML 413 response as shown in the screenshot, and traced the crash to unconditional
JSON.parse()calls in the upload handler. I updated the logic to parse responses defensively with `try/catch.Result
The frontend should not freeze or crash when the server returns HTML instead of JSON. Oversized uploads now fall back to the default error message.
Testing Instructions for a VM with nginx
413 Request Entity Too Largeand that the response body is HTML.Unexpected token '<'in the console.