SplitHTTP: Read and validate HTTP/1.1 responses#3797
Conversation
Changes made to read responses from a server (and check the response codes) before making a request if HTTPv1 is used
|
|
||
| var ( | ||
| ErrBadRespCode = errors.New("bad response code") | ||
| BadCodes = map[int]struct{}{502: {}, 503: {}, 505: {}} |
There was a problem hiding this comment.
everything but 200 OK is bad, can simplify this (also inline the ErrBadRespCode, it carries no type information anyway)
There was a problem hiding this comment.
Is it possible to have some "OK-like" codes there, like 100, 201, 202, and etc codes that may not require outputing the error? I wasn't sure about this so decided to make "bad codes" list on which we definitely need to return the error
There was a problem hiding this comment.
the server is xray, so we can define that 200 is the only valid status code here (you can check hub.go to see that this is the only successful status code in practice)
| // ConnHolder implements the net.Conn interface | ||
| // adds logic of reading the responses before writing the next request | ||
| // Used as a bugfix for HTTP1.1 | ||
| type ConnHolder struct { |
There was a problem hiding this comment.
since this thing is speciifc to h1 i suggest moving it into yet another file h1_connection (and renaming the constructor + type)
| // Used as a bugfix for HTTP1.1 | ||
| type ConnHolder struct { | ||
| ResponsesToRead int | ||
| Conn net.Conn |
There was a problem hiding this comment.
| Conn net.Conn | |
| net.Conn |
if you do this then you don't need to forward all the methods
|
|
||
| // Optimised to read only response codes | ||
| // Reads response codes until getting EOF or error | ||
| func ConnHttpReadRespCodes(conn net.Conn) (codes []int, err error) { |
There was a problem hiding this comment.
on second look, i think this will actually hang if the connection has not yet produced new responses, which is bad since it tries to read infinite amount of responses. I suggest to read one http response with net/http everytime there is a new request, and that's it.
|
这个 PR 等 @mmmray 的 approve |
SendUploadRequest reads responses, ConnHolder removed
|
@RPRX pairing with him on tg, I'll approve it when ready |
|
|
I think the deadline for tomorrow cannot be met with this and the UDP noise PR #3794 I also think neither PR is critical to release |
|
Relax, it can be delayed by a day or two. We don't have deadline, just a expected new release |
To prevent losing data due to some reader errors like EOF and to optimise the code
mmmray
left a comment
mmmray
left a comment
There was a problem hiding this comment.
I think this PR can be merged, except for one nitpick about some code comment
| // To reuse response reader, so we won't lose data | ||
| // If some EOF will accure |
There was a problem hiding this comment.
the reason you want to reuse the buf reader is because it sometimes reads more data than it returns, and returns the over-read data on the next Read call. so it's not related to EOF
|
@mmmray 这个 pr 改个合适的标题 |
mmmray
changed the title
|
|
4 participants
Changes made to read responses from a server
(and check the response codes) before making a request if HTTPv1 is used