-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Don't use responseType = blob | safari fails #481
Comments
Thanks for tracking this down. Ideally, we shouldn't be setting However, since we legitimately need to support non-text response types, such as when you use So for now, I don't see a way how we can avoid opting into blob mode when just reading text. If anyone has ideas, I would like to hear them. |
I'm running a forked version of your fetch in order to support streams but i don't think you would want it, adds to much dependencies.
But i'm not here to talk about that. The way i'm able to stream is by not setting any responseType so it's just plain text. That way I can use the progress event and get part of the response and then be able to stream it. if i would have used any other kind (arraybuffer, blob) then i wouldn't be able to slice it and stream it. So you maybe want to consider using just plain text if you ever want to support streams xhr.overrideMimeType('text/plain; charset=x-user-defined') if you are any interested in my fork then i can share it with you |
Interesting. I'd like to see a PR that makes this change, if you have the time. I'd prefer to see it separate from the streaming implementation, for clarity. |
My version is quite different cuz everything is transformed into stream no mather what you put in as argument into the Response constructor (the initbody fn). Even FormData gets transformed into a buffer/stream since i'm able to read it with the newest spec. I don't have So you could say that mine is built all around buffers/streams, where as you still keep the reference to string, Blob, FormData, typedArray etc. So it's not some easy cherry picking from my code exactly your response methods are very conditional... Mine is closer to the spec but ways a lot more (due to dependencies) But it maybe dosen't have to be so complicated as it may seems how about just switching if ('responseType' in xhr && support.blob) {
xhr.responseType = 'blob'
} to xhr.overrideMimeType('text/plain; charset=x-user-defined') I think it will mostly work out of the box. you are already handeling transformation of a string to a blob already in your response method when you do This is just exactly the reason why i went with my fork instead of your polyfill Only gotcha might be that some text response might not be the same when you call .text() since you no longer do the auto encoding stuff that browser dose
|
if you use overrideMimeType then you don't get the original content-type :( |
I am also having this issue in opera 25 running on a tv: One option may be to conditionally set responseType based on the response headers in the xhr.onreadystatechange = function() {
if (
xhr.readyState === XMLHttpRequest.HEADERS_RECEIVED &&
xhr.status === 200 &&
'responseType' in xhr &&
support.blob &&
xhr.getResponseHeader('Content-Type') !== 'application/json'
) {
xhr.responseType = 'blob'
}
}; This let's the tests pass, but I'm not sure about any other content types we would need to skip blob. |
We don't have to conditionally set the response type to blob. We need to change the response type to arraybuffer |
We are experiencing a performance hit with a lower powered device with one of our users - Apparently it runs out of memory. Now, I would like to discuss the best solution to see if can get this fixed here too. |
I believe this is fixed by #752 -- If I'm wrong and this is still an issue, please comment and I will reopen the issue and investigate some more :-) |
Ideally i think this should be reported to Safari but you could fix it much faster
I found out about this bug on a page that is running https
The result i'm getting is
The text was updated successfully, but these errors were encountered: