Description
On WASM, the standard http.Transfer
RoundTripper is not exposed for external use. Buildflags for wasm replace the standard implementation of RoundTripper with a special version that uses the browser Fetch API. The special JS RoundTripper does not seem to use or honor any of the documented settings provided by http.Transport
, such as Dial
or DialContext
. But the way the special JS RoundTripper is implemented as methods on http.Transport
, it prevents using the standard RoundTripper.
There are use cases for using the normal RoundTripper, for instance for testing and simulation in the browser. The normal RoundTripper is compiled and included in the binary anyway, and works perfectly well, but is masked by the browser version.
What version of Go are you using (go version
)?
go1.11
What operating system and processor architecture are you using (go env
)?
GOOS=js
GOARCH=wasm
What did you do?
I tried to configure a http.Client
to use a transport with a custom dial function:
https://play.golang.org/p/dnyTivQ643J
This works on all other platforms including the playground, but on WASM, the same, special Roundtripper is always used and there is no way to use the standard Roundtripper.
What did you expect to see?
Get https://api.ipify.org/: expected error, all ok
What did you see instead?
On WASM:
192.0.2.77
Done.
On other platforms, I get the expected result
Activity
andybons commentedon Sep 4, 2018
@neelance @dmitshur
antong commentedon Sep 4, 2018
I quickly tested two hacks to do this, and both seemed to work. Both pass the tests on normal platforms, but I don't know how to run the unit tests on WASM.
Hack 1: Don't implement the special RoundTripper on
http.Transport
, but make an own jsTransport. Set an instance of this ashttp.DefaultTransport
for GOARCH=wasm. Example: e8050daHack 2: Mod the special RoundTripper to instead use the normal RoundTripper if the caller has set options on the Transport. Example: 8137bf5
agnivade commentedon Sep 4, 2018
@johanbrandhorst
dmitshur commentedon Sep 4, 2018
This is also related to #25695.
rubensayshi commentedon Mar 7, 2019
running into this problem when trying to do HTTPS requests in wasm/js (using self signed certs over a websocket connection).
e8050da seems like an easy and clean solution to enable a lot more flexibility when desired.
as far as I can tell the only place where
http.Client
andhttp.Transport
are coupled to something that does not work in wasm/js is theDefaultTransport
usingnet.Dialer{}).DialContext
.Given a working
net.Dialer
the code inroundTrip
actually works just fine.I understand #25695 discusses a more major problem, but specially considering the impact of fixing that as a whole, maybe a simple fix like this would be a good start?
johanbrandhorst commentedon Mar 7, 2019
I agree Hack 1 as proposed by @antong is a reasonable short term approach. Are you interested in contributing this?
antong commentedon Mar 7, 2019
Sure! Do you mean that I should make a CL based on Hack 1 (e8050da)?
johanbrandhorst commentedon Mar 7, 2019
Yes, that sounds good.
net/http: expose standard transport for js
net/http: expose standard transport for js
gopherbot commentedon Mar 11, 2019
Change https://golang.org/cl/166617 mentions this issue:
net/http: expose standard transport for js
hullarb commentedon Dec 8, 2019
Hi all,
i just bumped into this issues as i tried to implement some tunneling for http request in wasm.
It's a pity that the above PR was abandoned.
i also have a very minimalistic change( 8327844) that i could use for testing my http tunneling.
As Transport currently does not provide any ways to customize the wasm/js RoundTrip behavior i wonder if it would not be fair to simple fallback to the "normal" roundTrip implementation in case a custom Transport struct is the caller and not the DeafultTransport (
the js RoundTrip implementation has already a fallback to the real transport RoundTrip implementation in case the fetch api is not available).
gopherbot commentedon Jun 25, 2021
Change https://golang.org/cl/330852 mentions this issue:
net/http: guarantee that the Transport dial functions are respected in js/wasm
net/http: guarantee that the Transport dial functions are respected i…