Re: Why does a route with unmatched conditions give 500 and not 404?
On Wed, Nov 12, 2008 at 9:44 PM, Mike Orr [EMAIL PROTECTED] wrote:
On Wed, Nov 12, 2008 at 2:00 AM, mario ruggier [EMAIL PROTECTED] wrote:
I would like to support specific http verbs on a given URI. For example, to
support GET and PUT for the URI /controller/action/id I have defined these
2 dedicated routes:
map.connect('/controller/action/:id', controller='controller',
action='GET_action', conditions=dict(method=['GET']))
map.connect('/controller/action/:id', controller='controller',
action='PUT_action', conditions=dict(method=['PUT']))
Issuing a GET or PUT for this (same) URI will cause the correct action to
be executed... however, if I issue a request with a different method, such
as a POST, the response is a 500 Internal Server Error. I would have
expected a 404 Not Found, as is normally returned for no matching route.
A simple workaround (amongst other more elaborate -- and imho more
convoluted -- local dispatching mechanisms) is to follow up the above
routes with a catchall for the any other verbs:
map.connect('/controller/action/:id', controller='controller',
action='OTHER_action')
that would then be supplied as a method on controller simply to return 404:
def OTHER_action(self, id):
abort(404)
So, why the 500 and not the 404 in the first place?
Any other suggestions of how best to handle such situations?
It should be 404 and it usually is. There must be a bug in how it
processes the particular argument combination. What happens if you
comment out the second route and remove the condition in the first?
If I do that then both GET and PUT (and all other verbs) requests are
routed to GET_action.
If (from the initial routes above) I instead comment out the PUT and
OTHER routes altogether (leaving the GET with its condition) and then
I request a PUT on same URI, the server responds with a 500:
NotImplementedError: Action u'action' is not implemented.
m.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Why does a route with unmatched conditions give 500 and not 404?
On Thu, Nov 13, 2008 at 2:58 AM, mario ruggier [EMAIL PROTECTED] wrote:
On Wed, Nov 12, 2008 at 9:44 PM, Mike Orr [EMAIL PROTECTED] wrote:
On Wed, Nov 12, 2008 at 2:00 AM, mario ruggier [EMAIL PROTECTED] wrote:
I would like to support specific http verbs on a given URI. For example, to
support GET and PUT for the URI /controller/action/id I have defined these
2 dedicated routes:
map.connect('/controller/action/:id', controller='controller',
action='GET_action', conditions=dict(method=['GET']))
map.connect('/controller/action/:id', controller='controller',
action='PUT_action', conditions=dict(method=['PUT']))
Issuing a GET or PUT for this (same) URI will cause the correct action to
be executed... however, if I issue a request with a different method, such
as a POST, the response is a 500 Internal Server Error. I would have
expected a 404 Not Found, as is normally returned for no matching route.
A simple workaround (amongst other more elaborate -- and imho more
convoluted -- local dispatching mechanisms) is to follow up the above
routes with a catchall for the any other verbs:
map.connect('/controller/action/:id', controller='controller',
action='OTHER_action')
that would then be supplied as a method on controller simply to return 404:
def OTHER_action(self, id):
abort(404)
So, why the 500 and not the 404 in the first place?
Any other suggestions of how best to handle such situations?
It should be 404 and it usually is. There must be a bug in how it
processes the particular argument combination. What happens if you
comment out the second route and remove the condition in the first?
If I do that then both GET and PUT (and all other verbs) requests are
routed to GET_action.
If (from the initial routes above) I instead comment out the PUT and
OTHER routes altogether (leaving the GET with its condition) and then
I request a PUT on same URI, the server responds with a 500:
NotImplementedError: Action u'action' is not implemented.
Is that what the action name should be, or does it always say 'action'?
I tried this and got 500 with development.ini and 404 with
production.ini. My error was NotImplementedError: Action
u'GET_action' is not implemented. If that's what's happening, it's
the correct behavior. In development mode it produces an interactive
traceback because it assumes you forgot to implement the method or the
route is wrong or something, and interactive tracebacks have status
500. When you set debug=false, it changes the error to 404 to avoid
giving any private information to potential attackers.
--
Mike Orr [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Why does a route with unmatched conditions give 500 and not 404?
On Thu, 13 Nov 2008 07:22:16 -0800, Mike Orr [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 2:58 AM, mario ruggier [EMAIL PROTECTED] wrote: NotImplementedError: Action u'action' is not implemented. Is that what the action name should be, or does it always say 'action'? It will show the real name of the action (the prematched action value, in the incoming URL... I tried this and got 500 with development.ini and 404 with production.ini. My error was NotImplementedError: Action u'GET_action' is not implemented. If that's what's happening, it's the correct behavior. In development mode it produces an interactive traceback because it assumes you forgot to implement the method or the route is wrong or something, and interactive tracebacks have status 500. When you set debug=false, it changes the error to 404 to avoid giving any private information to potential attackers. Ah, it is the debug mode, it does give 404 when debug is set to False... sorry about not realizing that it would behave differently because of this. Thanks a lot for pointing this out! m. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Why does a route with unmatched conditions give 500 and not 404?
I would like to support specific http verbs on a given URI. For example, to
support GET and PUT for the URI /controller/action/id I have defined these
2 dedicated routes:
map.connect('/controller/action/:id', controller='controller',
action='GET_action', conditions=dict(method=['GET']))
map.connect('/controller/action/:id', controller='controller',
action='PUT_action', conditions=dict(method=['PUT']))
Issuing a GET or PUT for this (same) URI will cause the correct action to
be executed... however, if I issue a request with a different method, such
as a POST, the response is a 500 Internal Server Error. I would have
expected a 404 Not Found, as is normally returned for no matching route.
A simple workaround (amongst other more elaborate -- and imho more
convoluted -- local dispatching mechanisms) is to follow up the above
routes with a catchall for the any other verbs:
map.connect('/controller/action/:id', controller='controller',
action='OTHER_action')
that would then be supplied as a method on controller simply to return 404:
def OTHER_action(self, id):
abort(404)
So, why the 500 and not the 404 in the first place?
Any other suggestions of how best to handle such situations?
mario
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Why does a route with unmatched conditions give 500 and not 404?
On Wed, Nov 12, 2008 at 2:00 AM, mario ruggier [EMAIL PROTECTED] wrote:
I would like to support specific http verbs on a given URI. For example, to
support GET and PUT for the URI /controller/action/id I have defined these
2 dedicated routes:
map.connect('/controller/action/:id', controller='controller',
action='GET_action', conditions=dict(method=['GET']))
map.connect('/controller/action/:id', controller='controller',
action='PUT_action', conditions=dict(method=['PUT']))
Issuing a GET or PUT for this (same) URI will cause the correct action to
be executed... however, if I issue a request with a different method, such
as a POST, the response is a 500 Internal Server Error. I would have
expected a 404 Not Found, as is normally returned for no matching route.
A simple workaround (amongst other more elaborate -- and imho more
convoluted -- local dispatching mechanisms) is to follow up the above
routes with a catchall for the any other verbs:
map.connect('/controller/action/:id', controller='controller',
action='OTHER_action')
that would then be supplied as a method on controller simply to return 404:
def OTHER_action(self, id):
abort(404)
So, why the 500 and not the 404 in the first place?
Any other suggestions of how best to handle such situations?
It should be 404 and it usually is. There must be a bug in how it
processes the particular argument combination. What happens if you
comment out the second route and remove the condition in the first?
--
Mike Orr [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
