rpcdaemon sending invalid responses #1450
Comments
|
tx I also noticed that normal transactions are not chunked. I wonder if this is specific only to responses that are chunked? |
|
I'm starting to suspect that this is an haproxy issue and not an rpcdaemon issue. I'll open an issue on their forums. |
|
HAProxy does not support chunk sizes larger than 2GB - I've filed a feature request to them but god only knows if they'll do it, or when... According to some of the go forms I've read this can be avoided by simply setting the Content-Length header before sending it off to the net/http server. I don't know if that's an option here? ...
// Check for an explicit (and valid) Content-Length header.
hasCL := w.contentLength != -1
...
if w.req.Method == "HEAD" || !bodyAllowedForStatus(code) {
// do nothing
} else if code == StatusNoContent {
delHeader("Transfer-Encoding")
} else if hasCL {
delHeader("Transfer-Encoding")
} else if w.req.ProtoAtLeast(1, 1) {
// HTTP/1.1 or greater: Transfer-Encoding has been set to identity, and no
// content-length has been provided. The connection must be closed after the
// reply is written, and no chunking is to be done. This is the setup
// recommended in the Server-Sent Events candidate recommendation 11,
// section 8.
if hasTE && te == "identity" {
cw.chunking = false
w.closeAfterReply = true
} else {
// HTTP/1.1 or greater: use chunked transfer encoding
// to avoid closing the connection at EOF.
cw.chunking = true
setHeader.transferEncoding = "chunked"
if hasTE && te == "chunked" {
// We will send the chunked Transfer-Encoding header later.
delHeader("Transfer-Encoding")
}
}
} else {
// HTTP version < 1.1: cannot do chunked transfer
// encoding and we don't know the Content-Length so
// signal EOF by closing connection.
w.closeAfterReply = true
delHeader("Transfer-Encoding") // in case already set
} |
Definitely an option, just need to find where to put it :) |
… (erigontech#1450) * Remove redundant writes when a state object is reverted (erigontech#21) * Remove redundant writes when a state object is reverted * Change IsDirty to Transaction level We don't want a reverted transaction to show up in written trace because it was touched by a previous transaction. * Add storage read whenever there is a sstore This fixes an issue when a storage slot is * written but got reverted * never read by sLoad opcode When this happens, we still need to include the storage slot in the trace. * fix test
I've been wracking my brain trying to figure out why
haproxyis complaining thatrpcdaemonis sending invalid responses.I've finally narrowed it down to the exact bytes that
haproxyis seeing in the reply that it doesn't like...In the below haproxy debugs you will see that it says
error at position 130which coresponds to this line00130 d8930676\r\nand I have absolutely no idea what that is...so I'm kinda stuck not knowing how I might resolve this. Was hoping someone would have some idea what that is.Even wireshark is telling me that the response is a malformed packet and does not parse the response correctly...
The curl command that reproduces this is quite ridiculous (the output is 3.4GB) but it's here:
haproxy error debug:
The text was updated successfully, but these errors were encountered: