Open brandonros opened 12 months ago
Hi @brandonros! Welcome to ureq!
I have never used WebAssembly myself, so I don't actually know what would be required to make that work. The Duration
here are ultimately used as socket timeouts. Those sockets are std::net::TcpStream
, and I'll imagine that even if we get past the Duration
problems, we will get to a dead end for the sockets. I don't know if it would be possible to solve that – blocking sockets at the bottom of the call stack?
A possible direction for a ureq 3.0, would be to isolate the HTTP request/response function into a Sans IO pattern backing library without allocations, deliberately target no_std and webassembly. Then make nice higher level wrappers for std, no_std and webasm that sits on the same core.
I'm curious @brandonros, what's the use case for using ureq in WebAssembly?
If it's useful, we could probably do something where all the meaningful features are stubbed out to fetch
, but we'd need some motivating use cases.
I do really like the idea of making a no_std version of ureq (with more user-friendly features stacked on top when std is present).
@jsha i've been thinking about the no_std thing.
Here's an experiment just fleshing out what a no_std low level API could look like: https://github.com/algesten/h1-call
Design goals:
no_std
and no alloc crate. Stack is enoughState
mean "the state the call is currently in", Version
means Http/1.0 or 1.1. Method
means GET/HEAD/etc...Version
HTTP/1.0
cannot send a body unless the Method
is POST
(the others are GET/HEAD which cannot have a body).I've fleshed out how this could look with HTTP/1.0 – but it looks pretty promising, albeit it's a type soup.
I'm curious @brandonros, what's the use case for using ureq in WebAssembly?
If it's useful, we could probably do something where all the meaningful features are stubbed out to
fetch
, but we'd need some motivating use cases.I do really like the idea of making a no_std version of ureq (with more user-friendly features stacked on top when std is present).
You're probably right. My "vision"/idea was probably due to a lack of understanding on how things should be done in wasm
land but the argument was:
write once, be able to run it backend (native Rust binary) and/or in the browser with wasm
without having to add logic like if backend, use ureq, otherwise, use web-sys fetch
https://github.com/search?q=repo%3Arustwasm%2Fwasm-bindgen%20fetch_with_request&type=code
Are there any updates on this? now the wasip2 is already out and having problems using reqwst and tokio in wasmtime. This project is the best alternative but currently not support the platform :(
@dipankardas011 I think we need a ureq 3.0 to make this work. I'm thinking there needs to be a clean separation between connection/transport handling and the http1.1 logic.
I'm in the process of structuring the underpinnings of such a rewrite, but it's slow work. Currently my main thinking is in this branch: https://github.com/algesten/hoot
The structure I have in mind is roughly that hoot is Sans-IO http1.1 impl leaving connection/transport handling to a higher layer in the ureq crate which means that can be realized either as TcpSocket or whatever is needed in webasm.
Np will wait
I don't know why I expected this to work with WebAssembly (it compiles for the
wasm32-unknown-unknown
target if you disable any TLS/SSL features).But you will get to JavaScript layer and have one of what I guess is many issues (how would it know to do HTTP over
fetch()
?):Which comes from
I read you can use Chrono::Duration (which does support WASM) but AgentBuilder would need to accept non std::time::Duration?