I have a CorsController whose job it is to respond crossdomain ajax headers (if the Origin is allows) whenever my application receives an OPTIONS request. But because I don't know exactly where that OPTIONS request will land, I have a catchall route at the top of my routes file set to catch any OPTIONS request to any path.
map.cors '*path',
:controller => 'cors',
:action => 'index',
:conditions => { :method => :options }
For actual OPTIONS requests, this works great. The problem comes in when the app should be serving a 404 Not Found.
Now what happens when I load /no/404/for/you (a path that my application does not handle a route for), I no longer get a 404. Instead this route get's activated and I get a 405 Method Not Allowed. This is causing our logs to be filled with errors that aren't really errors, and monitoring (like New Relic) to send out panic emails about error rates, when in reality everything is just fine.
It appears to see that the path matches, but the :conditions does not, and raises an exception. What interesting is that it appears the route handling is a 2 pass process. This cors route, at the top of my routes file, only triggers if there is an OPTIONS request (good) or if no other route declare after it matches and there is no static file at that path (bad).
Question:
How can I get this catch-all route to hit my controller for all OPTIONS requests, without it also intercepting and throwing errors about otherwise unmatched routes via GET, POST, PUT and DELETE?
And I need to do this, sadly, in Rails 2.x.
So you say
This cors route, at the top of my routes file, only triggers if there is an OPTIONS request (good) or if no other route declare after it matches and there is no static file at that path (bad).
You could add a route at the very end of your routes.rb that would match everything else and just return 404.
As your said it is kind of hacky but I don't see any other way to complete your catchall route at the top. Maybe someone will come up with something else.
Related
I'm coping some code from example inertia.js project, I copied organization put route, make action only return
return Redirect::back()->with('success', 'Organization updated.');
In the JS I just made request
this.form.put(`/organizations/1`)
In the Network I see two responses - first "/organizations/1" with 302 code and second - to my "/apples" route with error
"The PUT method is not supported for this route. Supported methods: GET, HEAD, POST."
What I need to do to redirect my request with "get" verb, not "put"?
I have a working Laravel project with loads of different routes.
I'm currently testing it and one of my tests was to check if a user were to use a delete or post route from the URL. I didn't know what the application would do honestly and it outputted the typical:
The GET method is not supported for this route. Supported methods: DELETE
which I have seen a million times. Is there a way to stop this error from coming up and instead output an error screen or simply redirect to a different view?
The error message:
The GET method is not supported for this route. Supported methods: DELETE.
should only appear when your Laravel site has APP_DEBUG set to true (in the .env file).
When APP_DEBUG is set to false as it should always be in on a live site, then the user will be shown a 404 error page instead.
You can easily test this by adding the following code to your routes file:
Route::delete('test', function() {
return 'You should never see this text when viewing url via a GET request';
});
May be u didn't noticed but ur form tag method attribute and route definition is different
I have a simple application (server side is Sinatra, client side is ReactJS).
The workflow is very basic: Sinatra handles get "/" request and sends an index.html to the client with static stylesheet and scripts.
Scripts are ReactJS app which consists of several components and a ReactRouter. Each React's component is a distinct "page" with its own route/path in terms of the ReactRouter.
For example:
"/" => "index.html" (real html page with renered components
inside),
"/form" => (ReactRouter points to component <Form/>, in fact render happens inside selector of "index.html"),
"/finish" => (ReactRouter points to component <Finish/>, in fact render happens inside selector of "index.html").
While I was implementing client side only, it worked pretty well. But now, when I am trying to use Sinatra for the server side stuff this is broken: when I want to go to the /form I am getting Sinatra's default 404 page ("Sinatra doesn’t know this ditty.").
I understand that Sinatra (or Rack) intercepts the request's path (/form of /finish) before the ReactRouter. But I cannot understand how to fix it (and why is it so, while router script is already on the client and should fire first).
Thanks for your help.
Use wildcard route to return index.html to all route.
Something like this:
get '/*' do
#return index.html
end
I implemented a small jruby sinatra app and if i run it directly on
WEBrick locally all the routings work perfectly. However when I deploy
the war file (i use warbler) to a server instance (like
"example.com/myapp" or "localhost:8080/myapp") I have routing
issues within the post requests.
For example:
get '/login' do
slim :login
end
post '/login' do
session.clear
login_correct? = check_password (params[:user], params[:pass])
if(login_correct?)
session[:user] = params[:user]
redirect to('/')
else
redirect to('/login')
end
end
get '/redirect' do
redirect to('/login')
end
Here the 3rd route handler (get '/redirect' do ..) redirects to
localhost:8080/myapp/login properly with status code 303, however 2nd route handler redirects
to localhost:8080/login with status code 404.
What should i do so that redirections in post route handler works
properly when i deploy the app?
Thanks a lot!
UPDATE on Solution: After checking the code again and again I realized that the problem was me using form action = '/login' in slim:login instead of form action= "#{url('/login')}". So it wasn't even handled by the post route handler since the post request was sent to localhost:8080/login but I thought it was route handler who is redirecting it to there..
try setting set :prefixed_redirects, true with Sinatra
(it should than use rack.env['SCRIPT_NAME'] with redirects)
UPDATE: even without the set :prefixed_redirects, true (default is false) works perfectly fine under Trinidad (which should behave the same as Warbler since bot use JRuby-Rack) ... request.env['SCRIPT_NAME'] is set to the /context_path correctly.
I would try updating (if they're not the latest) JRuby-Rack/Warbler as well as Sinatra as a last resort, otherwise this probably needs a detailed look at what's going on (esp. if SCRIPT_NAME is set correctly).
Say I have this route handler in my Express.js app:
app.get('/files/:name', function (req, res) {
res.sendfile('path/to/files/' + req.params.name + '.html');
});
This path is used via Ajax on my site. I wonder if I should guard against situations where a file with the requested name does not exist on the server, in which case the server returns a 404 response. I can work with this, i.e. detect the 404 in the browser and act accordingly (e.g. display a message to the visitor). However, I'm not sure if this is a good approach. Is it OK to use the 404 response here, or am I supposed to try to avoid 404 responses if possible. (E.g. I could if a file with the requested name exists on the server and only use .sendFile() if it does.)
I'm worried that performing a manual check would only slow things down as .sendFile() already has this check built-in (i.e. it's possible to avoid this check and instead detect 404 responses in the browser which is what I'm doing right now and it works fine).
I would stick with returning a 404 instead, as that's the 404's purpose.I'm not sure there really is any other common/practical alternative.
Good luck.