-
-
Notifications
You must be signed in to change notification settings - Fork 98
Description
We were using this gem for a while and never had problems with it, however, after we upgraded rack from 2.1.4.3 to 2.2.6.4 we started observing some issues with the way this gem parses a Rack:Request
. It's important to note that this only happens when running the app through docker.
In our Proxy we do:
class LocalProxy < Rack::Proxy
def perform_request(env)
request = Rack::Request.new(env)
if request.path.starts_with?("/some_service")
uri = URI.parse(ENV["PROXY_URL"])
env["HTTP_HOST"] = "#{uri.host}:#{uri.port}"
env["SERVER_PORT"] = uri.port
env["PATH_INFO"] = request.path.gsub("/some_service", "")
env["HTTP_COOKIE"] = ""
env["HTTP_X_FORWARDED_PROTO"] = "http"
env["rack.url_scheme"] = "http"
@port = uri.port.to_i
super(env)
else
@app.call(env)
end
end
end
The PROXY_URL
env var has a value of some_service:3001
. And when trying to access the http://localhost:3000/some_service
path we get an error: Failed to open TCP connection to some_service:3001:80 (getaddrinfo: Name or service not known)
. After spending some time investigating this it seems the issue is with the way a Rack::Request
is being parsed. Not sure if this is an issue with rack or on this gem's code. But wanted to point out something:
irb(main):005:0> r = Rack::Request.new({ "HTTP_HOST" => "http://some_service:3001" })
=> #<Rack::Request:0x0000aaaada21c0c0 @params=nil, @env={"HTTP_HOST"=>"http://some_service:3001"}>
irb(main):006:0> r.host
=> "http://some_service:3001"
irb(main):007:0> r.port
=> nil
# Using SERVER_PORT instead
irb(main):009:0> r = Rack::Request.new({ "HTTP_HOST" => "some_service", "SERVER_PORT" => 3001 })
=> #<Rack::Request:0x0000aaaad7a11fa8 @params=nil, @env={"HTTP_HOST"=>"some_service", "SERVER_PORT"=>3001}>
irb(main):010:0> r.host
=> "some_service"
irb(main):011:0> r.port
=> 3001
The code above is for rack 2. Rack 3 seems to handle the host parsing a lot better however setting a SERVER_PORT
should have worked but actually didn't. So I'm clueless and would like to know if anyone here has any ideas or have experienced something similar.
Also I'm intrigued by the fact that we were using the same rack-proxy version of 0.7.6 with rack 2.1.4.3 for a while and didn't have any issues. Which leads me to believe this might be a regression from: rack/rack#1606 which was backported to 2.2.6.4.
Rails version: 7.0.4
Ruby: 2.7.8
rack-proxy: 0.7.6
rack: 2.2.6.4