Skip to content
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.

Sign up for GitHub

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

Jump to bottom

multi: requests may get response for request issued in parallel (or timeout, or errors) #3956

Closed
TvdW opened this issue May 28, 2019 · 3 comments
Closed

multi: requests may get response for request issued in parallel (or timeout, or errors) #3956

TvdW opened this issue May 28, 2019 · 3 comments
Assignees
@bagder
Labels
HTTP HTTP/2

Comments

@TvdW
Copy link

TvdW commented May 28, 2019

https://gist.github.com/TvdW/f4815f8080d9dc30daa5d74b1f878dae

There's a nginx server running on 127.0.0.1, listening on port 80 for http/1.1, and on port 81 for http/2 (no TLS on either). I guess a simple nginx config to reproduce would be along the lines of

server {
listen *:80;
root /var/empty;
location / { }
}
server {
listen *:81 http2;
root /var/empty;
location / { }
}

Full log: https://gist.github.com/TvdW/37f7e01bf7b3b8763557d0a1c204379f

Seems to be a new bug in 7.65.0, 7.64.1 did not have it.
@TvdW TvdW mentioned this issue May 28, 2019
Closed
@TvdW
Copy link
Author

TvdW commented May 28, 2019

(This was originally reported as #3951 but I accidentally stumbled upon a different bug while minimizing the test case and reported that bug instead.)

@bagder
Copy link
Member

bagder commented May 28, 2019

Thanks for keeping me busy! 😁

@bagder bagder self-assigned this May 28, 2019
@bagder
Copy link
Member

bagder commented May 28, 2019 •
edited
Loading

I can reproduce the (unexpected) timeout. It seems to always be one of the h1 requests...

* Operation timed out after 1001 milliseconds with 0 bytes received
* Marked for [closure]: Disconnected with pending data

bagder added a commit that referenced this issue May 28, 2019
@bagder
url: default conn->port to the same as conn->remote_port
14680a7 
... so that it has a sensible value when ConnectionExists() is called which
needs it set to differentiate host "bundles" correctly on port number!

Probably a regression from 7.62.0

Reported-by: Tom van der Woerdt
Fixes #3956
@bagder bagder mentioned this issue May 28, 2019
Closed
bagder added a commit that referenced this issue May 28, 2019
@bagder
url: default conn->port to the same as conn->remote_port
d5ba8fc 
... so that it has a sensible value when ConnectionExists() is called which
needs it set to differentiate host "bundles" correctly on port number!

Probably a regression from 7.62.0

Reported-by: Tom van der Woerdt
Fixes #3956
bagder added a commit that referenced this issue May 28, 2019
@bagder
url: default conn->port to the same as conn->remote_port
b55f0dc 
... so that it has a sensible value when ConnectionExists() is called which
needs it set to differentiate host "bundles" correctly on port number!

Also, make conncache:hashkey() use correct port for bundles that are proxy vs
host connections.

Probably a regression from 7.62.0

Reported-by: Tom van der Woerdt
Fixes #3956
bagder added a commit that referenced this issue May 28, 2019
@bagder
url: default conn->port to the same as conn->remote_port
1248894 
... so that it has a sensible value when ConnectionExists() is called which
needs it set to differentiate host "bundles" correctly on port number!

Also, make conncache:hashkey() use correct port for bundles that are proxy vs
host connections.

Probably a regression from 7.62.0

Reported-by: Tom van der Woerdt
Fixes #3956
@bagder bagder closed this as completed in a6183ab May 28, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Aug 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@bagder bagder

Labels
HTTP HTTP/2
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

url: default conn->port to the same as conn->remote_port curl/curl
2 participants
@TvdW @bagder