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

[feat] access to URISchemeRequest body on Linux #666

Closed
1 of 2 tasks
JonasKruckenberg opened this issue Aug 21, 2022 · 9 comments
Closed
1 of 2 tasks

[feat] access to URISchemeRequest body on Linux #666

JonasKruckenberg opened this issue Aug 21, 2022 · 9 comments
Labels
platform: Linux status: upstream status: waiting Waiting for a response or another PR

Comments

@JonasKruckenberg
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Both the Rust type URISchemeRequest and upstream WebKitURISchemeRequest do not expose a way to access the requests body. For a variety of usecases including Tauri's IPC system it would be great if we could actually access the main content of the request.

Describe the solution you'd like
Implement this functionality in upstream projects mirroring the one from WKWebView URLRequest namely httpBody and httpBodyStream so we can consume the body both blocking and through a Rust Stream.

Describe alternatives you've considered
Not have access to the body on Linux and marking this as a platform difference, but sadly this is kind of a really important core feature. It being absent makes the custom protocol pretty useless.

Would you assign yourself to implement this feature?

  • Yes
  • No

Additional context
Add any other context or screenshots about the feature request here.

@wusyong
Copy link
Member

wusyong commented Dec 13, 2022

Do we have an upstream issue to track it?

@amrbashir
Copy link
Member

I don't think we opened one for it yet.

@TingPing
Copy link

This is tricky to implement in WebKitGTK.

There is no "request body" sitting around, it is a GInputStream that is read on-demand as network writes happen. In order to access a body a complete copy would have to be stored in-memory, which isn't reasonable in some cases.

@JonasKruckenberg
Copy link
Contributor Author

JonasKruckenberg commented Dec 13, 2022

Let's expose that stream though, we actually care much more about that stream than a full body. Wry itself already has code to read a stream into a Vec<u8> on macOS too

@TingPing
Copy link

"Just expose a stream" still has complications. It is possible for a stream to be read-once. In which case you have to copy the entire thing into memory. It is also possible for a stream to be GSeekable and read multiple times but you can't seek a stream that is being actively read somewhere else.

@TingPing
Copy link

I am mostly thinking about this from a libsoup perspective, the http library webkitgtk uses, its possible things work out nicer inside of WebKit.

@wusyong
Copy link
Member

wusyong commented Feb 20, 2023

Upstream issue created: https://bugs.webkit.org/show_bug.cgi?id=252564

@ModProg
Copy link

ModProg commented Sep 11, 2023

seems like the upstream issue was fixed: WebKit/WebKit#10714

@amrbashir
Copy link
Member

right, this has been implemented in wry behind linux-body feature flag

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform: Linux status: upstream status: waiting Waiting for a response or another PR
Projects
None yet
Development

No branches or pull requests

5 participants