-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XHRUploader does not work with responseType: json #5628
Comments
I'll take a look when I can Note that you don't need to do anything for the workaround. |
The issue with 'just using the default I do not know what the best way to fix this would be. Perhaps the 'cleanest' and 'simplest' approach would simply to change the default 'responseType' to 'json' as XHRPlugin seems to implicitly want 'json' responses; there is an explicit function to 'turn your non-JSON response into JSON' (https://uppy.io/docs/xhr-upload/#getresponsedata). However this would break any library user who was then trying to access While this plugin seems to assume the use of JSON formatted response data the underlying use of Thus what I think I'd suggest is that XHRUpload.#getFetcher 'res.response' (xhr.response) is 'normally' simply assigned to Furthermore the Proposed documentation: responseType This option sets the XMLHttpRequest.responseType property of the underlying XMLHttpRequest used for uploads. This xhr can be accessed in various callback functions such as getResponseData(). The default expectation of responses from your upload server is JSON data. However due to the getResponseData The response type should match your Uppy 'Body' specification. Ie If your response happens to be an object extending |
I should be able to open a PR for this (depending on exactly what fix is wanted). However I don't know that I have the schedule to do this anytime 'quick'. |
Thanks for all the details. I don't think we can switch the default I'll think about what makes the most sense. |
Initial checklist
Link to runnable example
https://stackblitz.com/~/github.com/bdirito/uppyXhruploadJson?file=main.js
Steps to reproduce
Open stackblitz. Open browser console. Upload any file from your machine.
The key aspects of this seem to be:
Create an Uppy instance, set the uploader plugin to XHRUploader. Set XHRUploader's option of
responseType
tojson
as specified in https://uppy.io/docs/xhr-upload/#responsetype. Upload a file such that the response is in json format.Expected behavior
The file will 'successfully' upload, and transition to 'green'. There should be no errors on the console. Callbacks that take an XHR should have
xhr.response
appropriately parsed.Actual behavior
The file perpetually sits 'in progress' at '100%'. There following error is printed to console:
InvalidStateError: Failed to read the 'responseText' property from 'XMLHttpRequest': The value is only accessible if the object's 'responseType' is '' or 'text' (was 'json').
The console error is a legit error as via https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/responseText
I've looked into this and I think the issue is the way https://github.com/transloadit/uppy/blob/main/packages/%40uppy/xhr-upload/src/index.ts handles stuff. From that file on L212 (I've removed some of the
fetcher
arguments):We do not have a
getResponseData
option so we try to parse the XHR'sresponseText
in uppy. But since the XHR has set itsresponseType
tojson
,responseText
is not available. In fact the whole logic here seems 'impossible'; the only way we could haveresponseText
available is ifresponseType
was either''
or'text'
. However in such a case you presumably should not be attempting to parse the response as json. On the other hand if the response is json you have no need to 're-parse' the data (and can not accessresponseText
).I did not further analyze why the upload is still 'in progress' - I assume its an artifact of the throw. Though even to the extent the throw was 'legitimate' I would expect the upload to be aborted with an error.
Workarounds
responseType
to''
or'text'
. (but actually return json). This means that you will have toJSON.parse(xrh.responseText)
yourself for any apis that you may want to use that are passing inxhr
(for exampleshouldRetry
oronAfterResponse
).getResponseData
to anoop
function.The text was updated successfully, but these errors were encountered: