It's nice that http-types compiles to WASM in the browser, even nicer would be to have a way to convert back and forth between the Request/Response types in this crate and the "native" JS Request/Response to avoid wrapping with a new type. The feature can be gated with a flag(e.g. web).
This is probably better and more general purpose than what I proposed in https://github.com/http-rs/http-client/issues/60 and can eventually simplify the code over there. I also think conversion could be made more efficient if the JS Request/Response body that is a ReadableStream(implements the asyncIterator protocol) is converted to a Stream/AsyncReader, modern Chrome even allows transferring those streams with the postMessage API so for my use case of intercepting requests from a ServiceWorker to be handled in a Worker(Using Rust and http-types) could be made much more efficient in the future.
It's nice that
http-typescompiles to WASM in the browser, even nicer would be to have a way to convert back and forth between the Request/Response types in this crate and the "native" JS Request/Response to avoid wrapping with a new type. The feature can be gated with a flag(e.g.web). This is probably better and more general purpose than what I proposed in https://github.com/http-rs/http-client/issues/60 and can eventually simplify the code over there. I also think conversion could be made more efficient if the JS Request/Response body that is aReadableStream(implements theasyncIteratorprotocol) is converted to a Stream/AsyncReader, modern Chrome even allows transferring those streams with the postMessage API so for my use case of intercepting requests from a ServiceWorker to be handled in a Worker(Using Rust andhttp-types) could be made much more efficient in the future.