Request#scheme SSL headers #534

Closed
moiristo opened this Issue Mar 27, 2013 · 3 comments

Comments

Projects
None yet
2 participants
@moiristo

One of our customers has a setup with proxies that route requests internally over http. Instead of any of the headers defined in Request#scheme (https://github.com/rack/rack/blob/master/lib/rack/request.rb#L70), the HTTP_X_HTTPS is sent. I've monkey-patched the method by checking for @env['HTTP_X_HTTPS'] == 'true'.

As I'm not sure how common this header is (Google returns only a few results), I don't think this case should be added to the method, but I think it would be nice if custom SSL headers could be configured somehow without monkey-patching the method.

@raggi

This comment has been minimized.

Show comment Hide comment
@raggi

raggi Apr 21, 2013

Member
class MyRequest < Rack::Request
  def scheme
    @env['HTTP_X_HTTPS'] == 'true' || super
  end
end
Member

raggi commented Apr 21, 2013

class MyRequest < Rack::Request
  def scheme
    @env['HTTP_X_HTTPS'] == 'true' || super
  end
end

@raggi raggi closed this Apr 21, 2013

@moiristo

This comment has been minimized.

Show comment Hide comment
@moiristo

moiristo Apr 21, 2013

Yeah... it is actually about a rails app. Rails already subclasses Rack::Request with ActionDispatch:Request, which I cannot substitute with my own class. I just thought that it would be nice if the massive if-block could be refactored to something more elegant and extendible. I'll stick with the monkeypatch for now.

Yeah... it is actually about a rails app. Rails already subclasses Rack::Request with ActionDispatch:Request, which I cannot substitute with my own class. I just thought that it would be nice if the massive if-block could be refactored to something more elegant and extendible. I'll stick with the monkeypatch for now.

@raggi

This comment has been minimized.

Show comment Hide comment
@raggi

raggi Apr 21, 2013

Member

There's no way to make it "extensible" in the way that you're talking about. In the same way that you're not in control of the type being created, you're also not in control of the options it would be constructed with.

You probably have some global singleton approach in mind, which is not an approach that we take.

Member

raggi commented Apr 21, 2013

There's no way to make it "extensible" in the way that you're talking about. In the same way that you're not in control of the type being created, you're also not in control of the options it would be constructed with.

You probably have some global singleton approach in mind, which is not an approach that we take.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment