* feat(fasthttpproxy): add dual-stack connection support to enable IPv6 proxies for HTTP and SOCKS5 dialers
- Added `FasthttpHTTPDialerDualStack` to support dual-stack (IPv4 and IPv6) connections for HTTP proxies, enabling IPv6 proxy usage.
- Added `FasthttpSocksDialerDualStack` to support dual-stack (IPv4 and IPv6) connections for SOCKS5 proxies, enabling IPv6 proxy usage.
- Improved dialer configuration to ensure compatibility with both IPv4 and IPv6 proxies.
* fix(lint): address linting issues in code
Replace the field `bufKV` with two `[]byte` fields and remove the filed `buf`.
- Reduce Cookie from **224** to **192** bytes.
- In the benchmark tests, although there is no significant performance improvement, it theoretically reduces memory usage by **14.3%**.
* add test which will cause error
* rename test
* fix improper memory reuse in NewFastHTTPHandler
* move deep copy from VisitAll to f
* copy value string only for cookie
* Remove a redundant field and clarify the comments.
* Revert "Using atomic instead of mutex and delete scratch slice (#1833)"
This reverts commit 19c50cdc44.
* Support for delayed retry logic
* Support for resetting the request timeout before retrying
* Users can decide whether to retry based on the request error and the number of retries.
Estimating the time required for a request to complete is relatively straightforward, but when retries are factored in, it becomes challenging to gauge this time accurately.
The current client implementation does not immediately return when encountering an RST packet while sending a request, but instead ignores it. This behavior is inconsistent with the net/http package and does not make logical sense.
In some cases, the goroutines started by one test do not terminate smoothly before the next round of tests begins, causing interference between tests.
Performance Impact: This results in test completion times not increasing linearly with the count value.
Correctness Impact: It affects the accuracy of memory allocation test cases.
The `testClientDoTimeoutError` and `testClientGetTimeoutSuccess` test function does not immediately return or fatal when the test fails. Instead, it continues to stringify the byte slice that was passed as the `dst` parameter to the `Client.GetTimeout` method. If the test fails due to a timeout, the request may still be ongoing, and there might be a data race between writing to `dst` and the stringification operation.
* using atomic instead of mutex and delete scratch slice
* optimize struct
* fix default bool
* escape data race
* avoid the momentary change of wp.workersCount.
* removed unused tail (for now)
* little fixes
* fixed allocations
This option immediately exits the loop when the maximum number of vorkers is reached, rather than creating a new vorker if the limit is reached. This reduces the frequency of unnecessary operations and potential locks in sync.Pool
* Update for linter workerpool.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Update for lint#2 workerpool.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Update for lint#3 workerpool.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Update for lint#4 workerpool.go
* eliminating potential data races
---------
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
Add a multifunctional `Dialer` struct and reimplement the function API
Reimplement the existing function interfaces of the fasthttpproxy package through Dialer. Refactor Dialer.GetDialFunc to ensure that its performance is comparable to the original function interfaces when the proxy does not change with the request address.
In the current implementation, there are several places where it's assumed that SetReadDeadline and similar functions logically won't affect a closed connection. However, these assumptions may not hold in certain specific situations. Therefore, instead of asserting that such errors will never occur, simply return the errors encountered during the execution of these methods.
Fix the MaxConns semaphore issue in HostClient.
Currently, the conns length and connsCount count in HostClient do not correctly implement the MaxConns semaphore mechanism.
This fix ensures that the waiter wake-up chain does not break.
* Reduce sizeof ResponseHeader and RequestHeader
+ Reduce ResponseHeader from 320 to 312 bytes
+ Reduce RequestHeader from 360 to 352 bytes
+ In the benchmark tests, although there is no significant performance improvement, it theoretically reduces memory usage by 2.2% to 2.5%.
* Remove redundant comment
* The StreamRequestBody should not read content beyond what is required.
The StreamRequestBody feature on the server side should not read content that does not belong to the current request body.This is more logical and consistent with the result of not using the StreamRequestBody feature.Fixes: https://github.com/valyala/fasthttp/issues/1816.
* Update server_test.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Update http.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
---------
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Fix RequestHeader parser (#1808)
When FastHTTP receives a header value suffixed or prefixed with tabs, they should be stripped.
* Remove redundant code
* Add test for header parser including tabs (#1808)
Kashiwa
Lavish
Oleksandr Redko
dependabot[bot]
Agustin Arce
Sigmund Xia 夏天睿
Kirill
newacorn
Erik Dubbelboer
NikoMalik
Juan Calderon-Perez