Skip to content
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

[RFC] Add support for missing XHR response types #6870

Closed

Conversation

davidaurelio
Copy link
Contributor

Fixes #6679

This adds support for the missing response types to XMLHttpRequest.
Don’t ship this yet. This is completely untested. yolo and stuff.

@facebook-github-bot
Copy link
Contributor

By analyzing the blame information on this pull request, we identified @davidaurelio, @sreesharp and @lexs to be potential reviewers.

@facebook-github-bot facebook-github-bot added GH Review: review-needed CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. labels Apr 7, 2016
@davidaurelio
Copy link
Contributor Author

@davidaurelio
Copy link
Contributor Author

@facebook-github-bot import

@facebook-github-bot
Copy link
Contributor

Thanks for importing. If you are an FB employee go to Phabricator to review.

this._sent = false;
this._lowerCaseResponseHeaders = {};

this._clearSubscriptions();
}

get responseType() {
return this._responseType;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

get/set properties not yet supported

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pity

@bestander
Copy link
Contributor

Your lint neglect is shameful

@davidaurelio
Copy link
Contributor Author

wanna take over?

break;

case 'blob':
this._cachedResponse = new global.Blob([this.responseText]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Blob constructor accepts some options including the MIME type of the response -- should we parse the HTTP response headers and pass the Content-Type to the Blob too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess that makes sense

@ide
Copy link
Contributor

ide commented Apr 7, 2016

Looks mostly good to me. I didn't look at the UTF-8 decoder too closely but assume it's right.

@facebook-github-bot
Copy link
Contributor

@davidaurelio updated the pull request.

@@ -44,8 +55,6 @@ class XMLHttpRequestBase {
readyState: number;
responseHeaders: ?Object;
responseText: ?string;
response: ?string;
responseType: '' | 'text';
status: number;
timeout: number;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

get/set properties not yet supported

@davidaurelio
Copy link
Contributor Author

Thanks for the review!

I didn't look at the UTF-8 decoder too closely but assume it's right.

it actually doesn’t handle surrogate pairs.

@facebook-github-bot
Copy link
Contributor

@davidaurelio updated the pull request.

@davidaurelio
Copy link
Contributor Author

@facebook-github-bot shipit

@davidaurelio
Copy link
Contributor Author

@bestander, this is ready for merge. I assume you have to accept it in phabricator

@facebook-github-bot
Copy link
Contributor

@davidaurelio updated the pull request.

@davidaurelio
Copy link
Contributor Author

@facebook-github-bot import

@facebook-github-bot
Copy link
Contributor

Thanks for importing. If you are an FB employee go to Phabricator to review.

@facebook-github-bot
Copy link
Contributor

@davidaurelio updated the pull request.

@davidaurelio
Copy link
Contributor Author

@ide, @bestander: as @javache assumed, ArrayBuffer / Uint8Array are unavailable on iOS7, even though they are activated in Safari.

What shall we do? Not support xhr.responseType = 'arraybuffer' at all? Setting it will throw an error on iOS7 right now. Android has support for it, I just checked the open source version

@bestander
Copy link
Contributor

Do we even support ios7?
Otis like 2012

On Friday, 8 April 2016, David Aurelio notifications@github.com wrote:

@ide https://github.com/ide, @bestander https://github.com/bestander:
as @javache https://github.com/javache assumed, ArrayBuffer / Uint8Array
are unavailable on iOS7, even though they are activated in Safari.

What shall we do? Not support xhr.responseType = 'arraybuffer' at all?
Setting it will throw an error on iOS7 right now. Android has support for
it, I just checked the open source version


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#6870 (comment)

@ide
Copy link
Contributor

ide commented Apr 8, 2016

Let's support arraybuffer responses on platforms that support it so that we don't hold back React Native for an OS with small market share. Apple says < 5% of users are on iOS 7.

This is the behavior I believe we want:

  • Responses of type arraybuffer work on Android and iOS 8+
  • React Native should not crash on iOS 7 if you never get an arraybuffer response
  • If you do get an arraybuffer response on iOS 7, we should fail quickly and with a clear error

This should work for apps that want to target iOS 7 and you can easily write code like: if (isIOS7) { dontFetchAnArrayBuffer(); }. And for apps that are iOS 8+ you get the functionality you expect.

@ide
Copy link
Contributor

ide commented Apr 8, 2016

@davidaurelio also could you add a comment to the code mentioning iOS 7 so that when we drop support for iOS 7 some day, it's easy to grep for deletable code?

}

/*eslint-disable no-bitwise */
exports.encode = (string: string): ArrayBuffer => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be missing something here, but doing utf8 ourself doesn't seem like something we should do.

Like the #1 rule of crypto "don't roll your own", I think this applies to string encoding too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the complexity of crypto and character encodings is very different. I have been looking for a compact utf-8 encoding lib, but didn’t find anything that was compact and solid at the same time. My implementation adds ~1KB when minified.

Do you have any specific concerns? We wouldn’t need to do this if we could pass the binary response data from native to JS wrapped into a host object we’d implement. That host object could pass of character encoding to a system service. I have been looking into JSC’s API for that, but as long as we pass messages as JSON, we can’t do it.

@facebook-github-bot
Copy link
Contributor

@davidaurelio updated the pull request.

@davidaurelio
Copy link
Contributor Author

@facebook-github-bot import

@facebook-github-bot
Copy link
Contributor

Thanks for importing. If you are an FB employee go to Phabricator to review.

@davidaurelio
Copy link
Contributor Author

@facebook-github-bot import

@facebook-github-bot
Copy link
Contributor

@davidaurelio updated the pull request.

@facebook-github-bot
Copy link
Contributor

Thanks for importing. If you are an FB employee go to Phabricator to review.

@ghost ghost closed this in fcc89e9 Apr 11, 2016
@ide
Copy link
Contributor

ide commented Apr 11, 2016

Cherry-picking this into 0.24-stable.

ide pushed a commit that referenced this pull request Apr 11, 2016
Summary:Fixes #6679

This adds support for the missing response types to XMLHttpRequest.
Don?t ship this yet. This is completely untested. yolo and stuff.
Closes #6870

Reviewed By: bestander

Differential Revision: D3153628

Pulled By: davidaurelio

fb-gh-sync-id: 76feae3377bc24b931548a9ac1af07943b1048ac
fbshipit-source-id: 76feae3377bc24b931548a9ac1af07943b1048ac
@mpretty-cyro
Copy link

@davidaurelio Just FYI the utf8 module this provides is supplanting a utf8 node module (https://github.com/mathiasbynens/utf8.js); I assume this is because of the '@providesModule' - should this really be doing that if all it does is encode?

@davidaurelio
Copy link
Contributor Author

@mpretty-homepass sorry about that :-( we’ll get rid of the special packager rule for react-native.

Feel free to send a PR that renames the module to something else.

zebulgar pushed a commit to nightingale/react-native that referenced this pull request Jun 18, 2016
Summary:Fixes facebook#6679

This adds support for the missing response types to XMLHttpRequest.
Don?t ship this yet. This is completely untested. yolo and stuff.
Closes facebook#6870

Reviewed By: bestander

Differential Revision: D3153628

Pulled By: davidaurelio

fb-gh-sync-id: 76feae3377bc24b931548a9ac1af07943b1048ac
fbshipit-source-id: 76feae3377bc24b931548a9ac1af07943b1048ac
wellmonge added a commit to wellmonge/react-native that referenced this pull request Feb 9, 2019
wellmonge added a commit to wellmonge/react-native that referenced this pull request Feb 9, 2019
cpojer pushed a commit to wellmonge/react-native that referenced this pull request Feb 11, 2019
cpojer pushed a commit to wellmonge/react-native that referenced this pull request Feb 11, 2019
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants