Most rails websites are fronted by a different webserver that acts as a proxy.
Set that proxy to handle static content and not even pass it to rails.
OK. That’s a good suggestion where there is a front-end proxy. In
this case, there isn’t. In any event, I would expect this to be a
very simple problem to solve and I only blamed my own ignorance for
the fact that I was having any difficulty at all. Am I to understand
that this is a problem which does not have a simple solution?
If you are wanting Rails to stop processing, what should it do?
What are you really wanting to achieve?
The normal use case is that static files are not served by Rails but
in that circumstance, another server would serve them before Rails.
If you wanted to serve them after Rails, then Rails shouldn’t stop
processing but pass the request on somehow.
If you are wanting Rails to stop processing, what should it do?
What are you really wanting to achieve?
I just want the URL to be served-up as a static page.
The normal use case is that static files are not served by Rails but
in that circumstance, another server would serve them before Rails.
I don’t understand that. As configured out-of-the-box Rails serves
the static page public/index.html as a home page. Although I have
never done it, I assume that I could simply modify that static page
and use it as the home page for a site. I just want to accomplish
essentially the same thing. I want to be able to have a few
static .html pages in public/static, e.g. public/static/test1.html.
In the case of this example, I don’t want ‘static’ to map to a
controller and ‘test1’ map to an action. It would be my understanding
that that is what would happen if there were some sort of beginning
instruction in the routes.rb file to the effect that if a URL begins
with /static there should be no further processing thus the standard
mappings to a controller and an action would just not be invoked WRT
that particular URL.
Anyway, I didn’t mean to get carried away here. I believed that I was
just missing some minor point and that someone would square me away
with ease. Apparently the point isn’t as trivial as I had thought.
the static page public/index.html as a home page. Â Although I have
that particular URL.
I think the point is that requests for the static pages never get as
far as routes.rb. They are handled before the processing gets to this
file so there is nothing that can be done in routes.rb to affect how
they are handled.
I believe you could use rails new feature which is rails metal, it makes
rails served the requested content without even touching the routing
mechanism. I never use it though, maybe you can find the documentation
on
the rails site.
You don’t need to change anything in your routes file for that to
work.
Any static files that exist in the public folder (eg all your images/
js/css or public/static/test1.html) will be served as static files.
Don’t forget that the url to browse to these files is /static/
test1.html and not /public/static/test1.html since it is the public
folder and not the rails root that is the webserver root directory.
Any static files that exist in the public folder (eg all your images/
js/css or public/static/test1.html) will be served as static files.
Well I’ll be darned! It works great. How do these files escape
being mapped by routes.rb? I notice that if I stick a file named
index.html in /static and then try to proceed to the /static URL in a
browser, Rails gives me a routing error. However, as you say, the
file /static/test.html serves up just fine. Now, if I could just
understand specifically why that is I think that I’d be finished with
this topic.
Don’t forget that the url to browse to these files is /static/
test1.html and not /public/static/test1.html since it is the public
folder and not the rails root that is the webserver root directory.
Yep, I totally have that. Thaks for pointing it out though as I do
often make stupid mistakes.
Thanks very much for the input.
.... doug
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.