Client.do calls didTimeout() on the error path (line 461), and the contract is
that send() returns a non-nil didTimeout whenever err != nil. TinyGo dropped
setRequestCancel but left the roundTrip error path returning the nil named
return value, so any http.Client{Timeout: ...} request whose dial failed (e.g.
connection refused) panicked with a nil func-value dereference instead of
returning the error. Return alwaysFalse on those error paths, matching the
other error returns in send().
Verified: http.Client{Timeout}.Get to a refused port now returns
"connection refused" instead of panicking.
* http: add ErrUseLastResponse and Client.CloseIdleConnections
Both are API-compatibility fills. ErrUseLastResponse is a sentinel a
CheckRedirect func returns to stop following redirects; nothing here has
to act on it beyond existing. CloseIdleConnections delegates to the
Transport when it has the method, which is what net/http does.
Programs that reference either currently fail to compile against this
package for want of a name, which is the whole cost.
This change introduces a CheckRedirect field to the http.Client struct in TinyGo,
mirroring the behavior of Go's standard library http.Client.
The purpose of this addition is to resolve build errors in projects that rely
on packages (such as golang.org/x/oauth2) expecting the Client to have a
CheckRedirect field. The field provides no functional change within TinyGo’s
HTTP client at this time — it is only included for API compatibility and
compilation success. There is no effect on runtime behavior unless explicitly
used by downstream code.
This PR adds a network device driver model called netdev. There will be a companion PR for TinyGo drivers to update the netdev drivers and network examples. This PR covers the core "net" package.
An RFC for the work is here: #tinygo-org/drivers#487. Some things have changed from the RFC, but nothing major.
The "net" package is a partial port of Go's "net" package, version 1.19.3. The src/net/README file has details on what is modified from Go's "net" package.
Most "net" features are working as they would in normal Go. TCP/UDP/TLS protocol support is there. As well as HTTP client and server support. Standard Go network packages such as golang.org/x/net/websockets and Paho MQTT client work as-is. Other packages are likely to work as-is.
Testing results are here (https://docs.google.com/spreadsheets/d/e/2PACX-1vT0cCjBvwXf9HJf6aJV2Sw198F2ief02gmbMV0sQocKT4y4RpfKv3dh6Jyew8lQW64FouZ8GwA2yjxI/pubhtml?gid=1013173032&single=true).