Missing template error responding to a path with a period via a catchall route #9654

Closed
jfirebaugh opened this Issue Mar 11, 2013 · 9 comments

Comments

Projects
None yet
5 participants
Contributor

jfirebaugh commented Mar 11, 2013

I have a route like the following:

  get '*path' => 'application#catchall'

The action for this route performs a default render of an catchall.html.erb template.

In a Rails 3.2, this action successfully responds to a URL with a path such as /foo.bar. With Rails 4, the same URL produces an error:

Missing template application/catchall with {:locale=>[:en], :formats=>[nil], :handlers=>[:erb, :builder, :raw, :ruby]}. Searched in: * "/Users/john/Development/scratch/app/views"

A sample app which exhibits this problem is available here. If you switch the Gemfile to Rails 3.2 you will see that it works.

Member

schneems commented Mar 11, 2013

What version of Rails 3.2 ? I'm running codetriage on 3.2.12 and it doesn't work unless you've got a format: false on the route https://github.com/codetriage/codetriage/blob/master/config/routes.rb#L37.

Either way add format: false and it should work fine.

Contributor

jfirebaugh commented Mar 11, 2013

Yes, 3.2.12. See the sample app -- comment the edge gem line and uncomment the 3.2.12 gem line to try it.

Yours is a put action -- perhaps it redirects rather than renders an html template?

Member

schneems commented Mar 11, 2013

I downloaded your app and started it:

$ bundle exec rails -v
Rails 4.0.0.beta1
ruby-1.9.3-p194  ~/documents/projects/rails-4-catchall (master)   
$ bundle exec rails s
=> Booting WEBrick
=> Rails 4.0.0.beta1 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
DEPRECATION WARNING: config.whiny_nils option is deprecated and no longer works. (called from block in <top (required)> at /Users/schneems/Documents/projects/rails-4-catchall/config/environments/development.rb:10)
config.eager_load is set to nil. Please update your config/environments/*.rb files accordingly:

  * development - set it to false
  * test - set it to false (unless you use a tool that preloads your test environment)
  * production - set it to true


[2013-03-11 10:00:08] INFO  WEBrick 1.3.1
[2013-03-11 10:00:08] INFO  ruby 1.9.3 (2012-04-20) [x86_64-darwin11.4.0]
[2013-03-11 10:00:08] INFO  WEBrick::HTTPServer#start: pid=5579 port=3000

Then visited localhost:3000/alkjsdflkajsdlfkj and it worked fine in both Rails 3.2.12 and Rails 4 (master)

What did I miss?

Contributor

jfirebaugh commented Mar 11, 2013

Try localhost:3000/foo.bar.

Member

schneems commented Mar 11, 2013

Sorry, it's early :) I can reproduce this, and confirm the behavior in 3.2.12. To let you know, you can set a default route on the application level using a before_filter like this: http://stackoverflow.com/questions/4643738/rails-3-respond-to-default-format

I'm not sure if the change you're seeing is intentional, or a regression. I'm going to check into it.

Owner

pixeltrix commented Mar 11, 2013

@jfirebaugh without a format: false the .bar gets treated as the request format and something has changed in 4.0 that appears to be preventing it from falling back to the HTML default. If you want .bar to be part of the path parameter then add format: false - I'm still trying to track down the responsible commit for the format fallback.

@ghost ghost assigned pixeltrix Mar 18, 2013

Contributor

gswirski commented Mar 30, 2013

The responsible commit is: c2267db.

gswirski added a commit to gswirski/rails that referenced this issue Apr 1, 2013

Reverts rendering behavior when format is unknown
If a request has unknown format (eg. /foo.bar), the renderer
fallbacks to default format.

This patch reverts Rails 3.2 behavior after c2267db commit.

Fixes issue #9654.

pixeltrix added a commit that referenced this issue Apr 10, 2013

pixeltrix added a commit that referenced this issue Apr 10, 2013

Reverts rendering behavior when format is unknown
If a request has unknown format (eg. /foo.bar), the renderer
fallbacks to default format.

This patch reverts Rails 3.2 behavior after c2267db commit.

Fixes issue #9654.
Owner

pixeltrix commented Apr 10, 2013

Fixed by d50df2f

@pixeltrix pixeltrix closed this Apr 10, 2013

tienn-zz pushed a commit to square/rails that referenced this issue Jul 2, 2014

Reverts rendering behavior when format is unknown
If a request has unknown format (eg. /foo.bar), the renderer
fallbacks to default format.

This patch reverts Rails 3.2 behavior after c2267db commit.

Fixes issue #9654.

matthijsgroen pushed a commit to matthijsgroen/konacha that referenced this issue Jul 23, 2014

Use `:format => false` for the other catchall route
This fixes a Rails 4 compatibility issue. I filed an
upstream bug for investigation:

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