Rum validation
Mark Ramm
errors. I'm not sure this is the correct response code, but I'm a
little bit unsure what the "right" way to do it is, but I think that a
409 or "Conflict" might be the most applicable status code.
From the RFC
10.4.10 409 Conflict
The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict and
resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem; however, that might not be
possible and is not required.
Conflicts are most likely to occur in response to a PUT request. For
example, if versioning were being used and the entity being PUT
included changes to a resource which conflict with those made by an
earlier (third-party) request, the server might use the 409 response
to indicate that it can't complete the request. In this case, the
response entity would likely contain a list of the differences between
the two versions in a format defined by the response Content-Type.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
Alberto Valverde
modification conflict (leveraging the magic SA does with the version_id
field). The phrase from the quote you posted I think supports this
reasoning is: "The request could not be completed due to a conflict
*with the current state of the resource*", that is, when updating
(PUTing) a resource that already exists, which is what Rum is doing ATM.
I believe a 400 is a correct response status for validation errors since
it means "Bad Request" which invalid form data I believe is. From the RFC:
"10.4.1 400 Bad Request: The request could not be understood by the
server due to malformed syntax. The client SHOULD NOT repeat the request
without modifications."
Which I think applies to a bad form submission since it has "malformed
syntax" (ie: not in the format the application expects) so the client
should modify (correct errors) before repeating it. There was a thread
in pylons-discuss regarding this same issue some time ago which also
supports this argument:
http://groups.google.com/group/pylons-discuss/browse_thread/thread/acd72479217cf017
Moreover, I haven't encountered any browser that handles this status
code incorrectly (the user doesn't even notice unless using Firebug,
Live HTTP headers or something similar) and I think it can make scripted
clients' live easier since a status code is easier to parse than
scrapping the returned page for errors.
Is this 400 causing any problems somewhere?
Alberto
P.S. See you all tomorrow at the sprint, I got stranded today
researching work related stuff at home :( Luckily I have little Felisa
by my side to cheer me up :) (Sorry for the off-topic pic in advance,
I'm still in the drooling phase ;)
Mark Ramm
Michael Brickenstein
> Is this 400 causing any problems somewhere?
http://toscawidgets.org/trac/rum/ticket/51
http://docs.turbogears.org/2.0/RoughDocs/Rum
from TG2: tg.configuration:
def add_error_middleware(self, global_conf, app):
"""Adds middleware which handles errors and exceptions"""
app = ErrorHandler(app, global_conf, **config
['pylons.errorware'])
# Display error documents for 401, 403, 404 status codes (and
# 500 when debug is disabled)
if asbool(config['debug']):
app = StatusCodeRedirect(app)
else:
app = StatusCodeRedirect(app, [400, 401, 403, 404, 500])
return app
Best regards to you and Felisa,
Michael