* adding hijack method and pass proper fields
* adding hijack method and pass proper fields - adding tests
* improve hijack handling, use proper test for hijacking
* extend hijackhandler propogation to NewFastHTTPHandlerFunc
* align hijacking of fasthttp adaptor net request with fasthttp request, safe conn handling for proper release of resources and custom hijack handler for more controlled by hijacking implementation
* Implement actual behaviour of net/http Hijacker
---------
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Prevent request smuggling
Prevent request smuggling when fasthttp is behind a reverse proxy that
might interprets headers differently by being stricter. Should also
prevent request smuggling when fasthttp is used as the reverse proxy.
* Make header value comparison case-insensitive
From the Go docs:
- Fuzz targets should be fast and deterministic so the fuzzing engine can work efficiently, and new failures and code coverage can be easily reproduced.
- Since the fuzz target is invoked in parallel across multiple workers and in nondeterministic order, the state of a fuzz target should not persist past the end of each call, and the behavior of a fuzz target should not depend on global state.
or an *io.LimitedReader of an *os.File (because that's also supported by
https://cs.opensource.google/go/go/+/refs/tags/go1.21.4:src/bufio/bufio.go;l=784)
I think that having to flush less often outweighs the overhead of the
extra check. The appended data is known to be large, but it might still
save us a syscall by allowing it to buffer more.
These are the same statements at the beginning of io.CopyBuffer, but
by doing them ourselves first we trade off a little cpu for not holding
the 4kb buffer during the write.
A few lines later we check if `s.ReduceMemoryUsage && hijackHandler == nil`
and call releaseWriter. We need to flush the buffer before returning it
to the pool to avoid the data getting lost.
- I noticed that fasthttp was taking up 1.8MB of heap memory, even
though it wasn't being used. This turned out to be the stackless
function: 1.80MB github.com/valyala/fasthttp/stackless.NewFunc
- Lazy load the stackless functions with sync.Once, given this a simple
atomic read, it shouldn't affect performance for the fast-path (I
haven't seen benchmarks with compression enabled).
* substitute *os.File by fs.File
* refactor error handling by using the new recommended form
* finish implementation
* substitute seek(offset,0) by seek(offset, io.SeekStart)
* add unit test
* use io.SeekStart on Seek method
* Allow redirect URI path to not be normalized.
* Introduce DisableRedirectPathNormalizing field to Request
* Use field name as start of comment.
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
---------
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
Oleksandr Redko
gilwo
dependabot[bot]
Erik Dubbelboer
Juan Calderon-Perez
mopeneko
Zhengkai Wang
tyltr
nickajacks1
AdamKorcz
Oleksandr Redko
Jille Timmermans
Aviv Carmi
Gusted
Tiago Peczenyj
Tiago Peczenyj
Scott Kidder
chenyunfei
Alexander Kolesov
xiluoxi