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.

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

Rails 3 rack-mount optimization doesn't work for constraints #15

Open
clemens opened this issue Nov 19, 2010 · 8 comments
Open

Rails 3 rack-mount optimization doesn't work for constraints #15

clemens opened this issue Nov 19, 2010 · 8 comments

Comments

@clemens
Copy link

clemens commented Nov 19, 2010

It seems that the monkeypatches for the rack-mount optimizations don't work properly when using constraints in routes.

See this gist: https://gist.github.com/705804

URLs with subdomains are recognized correctly but not URLs without subdomains. As soon as I comment out the code generation stuff in routing filter, recognition works (but obviously routing filter doesn't work anymore).

I'm not 100% this is a problem specific to the constraints method – it could affect other aspects of routing, too.

@svenfuchs
Copy link
Owner

I see.

Can someone provide a failing test case, please?

@clemens
Copy link
Author

clemens commented Dec 27, 2010

Here it is: clemens@01a9206.

@clemens
Copy link
Author

clemens commented Dec 27, 2010

Actually the constraints line should go before the other one because it's more specific (that's the rule in Rails 3, right?). What stays the same is that stuff is failing.

I still don't have a clue about the problem but one hint might be that constraint handling is a Rack middleware itself that relies on the X-Cascade header. So maybe routing filter needs to somehow take that into account? Just musing ...

@svenfuchs
Copy link
Owner

Ah, thanks for the test case, Clemens.

Will have a look asap, although ... that might be next year ;)

@svenfuchs
Copy link
Owner

Ok, I've had a look already.

The problem is related to the fact that Rack::Mount::RouteSet#call yields a block to recognize and this block calls return in order to break out of the optimized_each loop. Therefor it is not possible to actually wrap around that block. Whenever that return is called it will immediately return to the original method no matter how many filtering blocks are wrapped around that inner block. Yeah, that's just like using GOTO behaved in BASIC in 1982.

I'm not sure how to get around this. I can't believe this stuff is so fricking hard, but it seems it actually is.

@dvandersluis
Copy link

Has any progress on this issue ever been made? I'm running into the same thing myself and in trying to figure out a solution came to the same conclusions as you did a year ago, @svenfuchs.

@ygor
Copy link

ygor commented Jun 12, 2012

I just ran into this problem too! Any ideas on how to fix it?

@ygor
Copy link

ygor commented Jun 12, 2012

Ok, this fixes the problem I think, but of course is not a nice fix. I think an easy fix is not possible without refactoring parts of the core of this gem. Sven what do you think?

def recognize_with_filtering(request, &block)
  path, route, matches, params = request.env['PATH_INFO'], nil, nil, nil
  original_path = path.dup

  # first run of filters to possibly change the request path
  filters.run(:around_recognize, path, request.env) {{}}

  recognize_without_filtering(request) do |route, matches, params|
    request.env['PATH_INFO'] = original_path
    filters.run(:around_recognize, original_path, request.env) do
      params || {}
    end
    request.env['PATH_INFO'] = original_path
    if block_given?
      block.call(route, matches, params)
    else
      return route, matches, params
    end
  end
  nil
end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants