-
Notifications
You must be signed in to change notification settings - Fork 391
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
Inconsistent behavior between Android and iOS version #216
Labels
Comments
robertohuertasm
added a commit
to robertohuertasm/cordova-plugin-ionic-webview
that referenced
this issue
Nov 14, 2018
…e is not found Currently, the Android version of the plugin always returns http code 200 no matter if the resource you're trying to get exists or not. The iOS version does. This makes the two implementations inconsistent. This tries to fix that and use the same expected behavior in both of them. BREAKING CHANGE: Until now, the Android part of the plugin was returning a 200 http code even though the requested file didn't exist. This behavior was inconsistent with the historical behavior of the iOS webView. This change makes them both work in the same manner but introduces a breaking change for the current Android users that are expecting a 200 http code no matter what and are testing the not found error just by checking if the body is null. fix ionic-team#216
jcesarmobile
pushed a commit
that referenced
this issue
Dec 12, 2018
…e is not found (#217) Currently, the Android version of the plugin always returns http code 200 no matter if the resource you're trying to get exists or not. The iOS version does. This makes the two implementations inconsistent. This tries to fix that and use the same expected behavior in both of them. BREAKING CHANGE: Until now, the Android part of the plugin was returning a 200 http code even though the requested file didn't exist. This behavior was inconsistent with the historical behavior of the iOS webView. This change makes them both work in the same manner but introduces a breaking change for the current Android users that are expecting a 200 http code no matter what and are testing the not found error just by checking if the body is null. fix #216
Ionitron
added a commit
that referenced
this issue
Jan 3, 2019
# [3.0.0](v2.3.1...v3.0.0) (2019-01-03) ### Bug Fixes * **iOS:** Remove unused code ([#247](#247)) ([bceb17a](bceb17a)) ### Features * Allows configuration of Mixed Content Mode ([#240](#240)) ([486d412](486d412)), closes [#231](#231) * **Android:** Implement ionic-file and ionic-content urls ([#242](#242)) ([8ef0c30](8ef0c30)), closes [#204](#204) [#183](#183) * **iOS:** Remove GCDWebServer ([#244](#244)) ([0dee0cf](0dee0cf)) * **WebViewLocalServer.java:** return 404 error code when a local file is not found ([#217](#217)) ([f7a551e](f7a551e)), closes [#216](#216) ### BREAKING CHANGES * **iOS:** Sets deployment-target to 11, so will only work on iOS 11+ * Address changes * changes the default from 1 (never) to 0 (always) * **WebViewLocalServer.java:** Until now, the Android part of the plugin was returning a 200 http code even though the requested file didn't exist. This behavior was inconsistent with the historical behavior of the iOS webView. This change makes them both work in the same manner but introduces a breaking change for the current Android users that are expecting a 200 http code no matter what and are testing the not found error just by checking if the body is null.
🎉 This issue has been resolved in version 3.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've been looking into the behavior of the Android version and it seems to be returning
200
instead of404
error codes whenever it can't find a local asset. For what I've been able to see, this behavior seems to be there since the beginning of the Android support.@mlynch, could you disclose why this was implemented like that? Maybe there's something that I'm missing because I don't see many people complaining about this and I don't seem to find it either in the documentation.
Thanks!
// related to #114
The text was updated successfully, but these errors were encountered: