Bug 232653 – [GTK][WPE] Support getting and setting HTTP headers in custom URI scheme handlers

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebKitGTK

This is a continuation of https://bugs.webkit.org/show_bug.cgi?id=231880.

Currently, there is no way for the URI scheme handler to get or set the HTTP headers.
As the last patch has proven, the URI scheme handler should also be considered to be HTTP-compliant since `fetch` or `XHR` calls to the URI scheme handler contains full HTTP information.

Those functionalities are necessary, because:
* The same functionality already exists in the macOS version of the WebKit implementation (by manipulating `NSHTTPURLResponse` and/or `NSHTTPURLRequest`)
* Could eliminate the usage of a local server: this could ease the development of semi-native apps, especially in the embedded environment
* Existing workaround to get HTTP headers from URI scheme is unreliable (see the bug report below)
* There are already feature requests for this: https://bugs.webkit.org/show_bug.cgi?id=231564

After this patch is landed, https://bugs.webkit.org/show_bug.cgi?id=231564 will be completely fixed.

Created attachment 443165 [details]
Patch

[EWS Watchlist]

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

Created attachment 443172 [details]
Patch

[Michael Catanzaro]

I'm confused by so many different bug reports for very similar issues.

Isn't this a duplicate of bug #203273?

And also of bug #231564, asides from that bug's reference to methods, which you already solved in bug #231880?

I would mark both this and bug #231564 as duplicates of bug #203273, and continue there, so we only have one bug report to deal with. Do you agree?

(In reply to Michael Catanzaro from comment #4)
> I'm confused by so many different bug reports for very similar issues.
> 
> Isn't this a duplicate of bug #203273?
> 
> And also of bug #231564, asides from that bug's reference to methods, which
> you already solved in bug #231880?
> 
> I would mark both this and bug #231564 as duplicates of bug #203273, and
> continue there, so we only have one bug report to deal with. Do you agree?

Sorry for the confusion. If this bug report is marked duplicate, what would happen to the patch review?

[Michael Catanzaro]

Just upload it again in the bug that is not closed!

(In reply to Michael Catanzaro from comment #6)
> Just upload it again in the bug that is not closed!

Thank you, I will mark this bug as a duplicate.

*** This bug has been marked as a duplicate of bug 203273 ***