Steps to reproduce: 1. Use webkit_web_context_register_uri_scheme(), e.g. "myscheme", make the callback always finish requests with a valid GInputStream (for example, return the "Hello world" string for any requested URI). 2. Load a page that contains this: fetch("myscheme:/someresource", {mode: "no-cors"}) .then(response => { console.log("Status:", response.ok, response.status) response.text().then(text => { console.log("Text:", text); }); }) .catch(console.error); Expected outcome ---------------- * The response is considered successful. * The logged output contains: Status: true 200 Text: Hello, world Actual outcome -------------- * The response is NOT considered successful, yet the * The logged output contains: Status: false 0 Text: Hello, world
This is somewhat related to bug #203273 but much, much smaller in scope, and I think setting the status to “200 OK” when an URI scheme request is finished with a valid “GInputStreams” should not be controversial, so let's tackle this small annoyance first.
Created attachment 421653 [details] Patch
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See https://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Committed r273618: <https://commits.webkit.org/r273618> All reviewed patches have been landed. Closing bug and clearing flags on attachment 421653 [details].
Comment on attachment 421653 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=421653&action=review > Source/WebKit/ChangeLog:8 > + No new tests needed. This should be easy to add a unit test for, especially if you care about not regressing this functionality in the future.
We have recently added api to set the response, including api tests for checking the status and message.