-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
"time" | ||
) | ||
|
||
var ( | ||
ErrBadRespCode = errors.New("bad response code") | ||
BadCodes = map[int]struct{}{502: {}, 503: {}, 505: {}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 改个合适的标题 |
|
Changes made to read responses from a server
(and check the response codes) before making a request if HTTPv1 is used