Hi,
I''m going to use remote forms, and thought to pass information back
thanks to the HTTP status code of the request when the submission went
wrong due for example to unacceptable data being submitted. In this
scenario, the form is well submitted but generates an error. Would it
be correct to use eg return code 493 so that I ctake specific action
for a form submitted with invalid data, like (adapted from example at
http://api.rubyonrails.com/classes/ActionView/Helpers/JavaScriptHelper.html#M000395)
:url => { :action => "action" },
493 => "alert(''You submitted invalid
data!'')",
404 => "alert(''Form processing not
found?'')",
:failure => "alert(''HTTP Error '' +
request.status + ''!'')"
I''m looking for the best way to let the calling javascript know that
the form was processed but that the data was invalid, so that it can
take action (I would pass some additional info in the response body,
like which field was invalid).
Thanks.
Raph
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Please don''t go inventing your own status codes. The list of HTTP
1.1 status codes is at http://www.w3.org/Protocols/rfc2616/rfc2616-
sec10.html
Please read the standards for yourself, but I would think the old 500
Internal Server Error is the correct status code for unacceptable
data. From the RFC: "The server encountered an unexpected condition
which prevented it from fulfilling the request." Other people on the
list may be able to point to a better status code than that.
Some of the other codes may look tempting, but should *not* be used
in response to unacceptable form data are: 400 Bad Request, 405
Method Not Allowed, 406 Not Acceptable, 412 Precondition Failed, 417
Expectation Failed
Someone more versed in HTTP semantics may correct some of the above
descriptions of status codes, but my core advice ("Please don''t go
inventing your own status codes") still stands.
George
- --
George Hotelling GPG: 0x8175D485 ]
http://george.hotelling.net ]
_ _ _ ___ _ _ _/
On Aug 23, 2005, at 3:25 PM, Raphael Bauduin wrote:
> I''m going to use remote forms, and thought to pass information
back
> thanks to the HTTP status code of the request when the submission went
> wrong due for example to unacceptable data being submitted. In this
> scenario, the form is well submitted but generates an error. Would it
> be correct to use eg return code 493 so that I ctake specific action
> for a form submitted with invalid data
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDC4z8gXVRXIF11IURAhkOAJ9VYk5R5BLz19VZbEMt5FcTWmWYxACfQclN
dshQYgONe0Kg+BSA7qBFoN4=LjRI
-----END PGP SIGNATURE-----
Amen! 500 sounds good to me. As far as I can remember the status codes are all for *the protocol* and not for what data the protocol carries. Which means that the status-codes might or will actually use your codes to adapt it''s behavior (i.e. thinking that the status code you sent actually means something in regards to *how* the data is being transported. ------------------------------------------------------------------------ /*Ronny Hanssen*/ George Hotelling wrote:> Please don''t go inventing your own status codes. The list of HTTP 1.1 > status codes is at http://www.w3.org/Protocols/rfc2616/rfc2616- sec10.html > > Please read the standards for yourself, but I would think the old 500 > Internal Server Error is the correct status code for unacceptable > data. From the RFC: "The server encountered an unexpected condition > which prevented it from fulfilling the request." Other people on the > list may be able to point to a better status code than that. > > Some of the other codes may look tempting, but should *not* be used in > response to unacceptable form data are: 400 Bad Request, 405 Method Not > Allowed, 406 Not Acceptable, 412 Precondition Failed, 417 Expectation > Failed > > Someone more versed in HTTP semantics may correct some of the above > descriptions of status codes, but my core advice ("Please don''t go > inventing your own status codes") still stands. > > George > -- > George Hotelling GPG: 0x8175D485 ] > http://george.hotelling.net ] > _ _ _ ___ _ _ _/ > > > On Aug 23, 2005, at 3:25 PM, Raphael Bauduin wrote: > >>> I''m going to use remote forms, and thought to pass information back >>> thanks to the HTTP status code of the request when the submission went >>> wrong due for example to unacceptable data being submitted. In this >>> scenario, the form is well submitted but generates an error. Would it >>> be correct to use eg return code 493 so that I ctake specific action >>> for a form submitted with invalid data > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 8/23/05, George Hotelling <george-s1Z0Dg4i37rMFIMGWPqnnw@public.gmane.org> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Please don''t go inventing your own status codes. The list of HTTP > 1.1 status codes is at http://www.w3.org/Protocols/rfc2616/rfc2616- > sec10.html > > Please read the standards for yourself, but I would think the old 500 > Internal Server Error is the correct status code for unacceptable > data. From the RFC: "The server encountered an unexpected condition > which prevented it from fulfilling the request." Other people on the > list may be able to point to a better status code than that. >Just FYI, I''ve indeed consulted the rfc before sending my mail ;-) But if we go with standard error codes, why use code in the 5XX, and not in the 4XX (from the rfc: "The 4xx class of status code is intended for cases in which the client seems to have erred") as it is the client that sends bad data? I was also not sure I should use standard return codes, as the request is actually well processed, just that it is not correct data. But even in that case, the 400 seems also good: " The client SHOULD NOT repeat the request without modifications." Anyway, like Ronny said maybe I shouldn''t even use HTTP return codes as those are meant for the HTTP protocol, not the application communicating over http....... (for the 400 again: "The request could not be understood by the server due to malformed syntax.") But then, what''s the best way to let my form_remote_tag know which action to take (proceed if form was processed fine, give alert if some fields in the form were not correct) ? Thanks for any and all advice. Raph
Raphael Bauduin wrote:> On 8/23/05, George Hotelling <george-s1Z0Dg4i37rMFIMGWPqnnw@public.gmane.org> wrote: > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Please don''t go inventing your own status codes. The list of HTTP >>1.1 status codes is at http://www.w3.org/Protocols/rfc2616/rfc2616- >>sec10.html >> >>Please read the standards for yourself, but I would think the old 500 >>Internal Server Error is the correct status code for unacceptable >>data. From the RFC: "The server encountered an unexpected condition >>which prevented it from fulfilling the request." Other people on the >>list may be able to point to a better status code than that. >> > > > Just FYI, I''ve indeed consulted the rfc before sending my mail ;-) > But if we go with standard error codes, why use code in the 5XX, and > not in the 4XX (from the rfc: "The 4xx class of status code is > intended for cases in which the client seems to have erred") as it is > the client that sends bad data? > > I was also not sure I should use standard return codes, as the request > is actually well processed, just that it is not correct data. > But even in that case, the 400 seems also good: " The client SHOULD > NOT repeat the request without modifications." > > Anyway, like Ronny said maybe I shouldn''t even use HTTP return codes > as those are meant for the HTTP protocol, not the application > communicating over http....... > (for the 400 again: "The request could not be understood by the server > due to malformed syntax.") > > But then, what''s the best way to let my form_remote_tag know which > action to take (proceed if form was processed fine, give alert if some > fields in the form were not correct) ? > > Thanks for any and all advice. > > Raph > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > >What do you mean by ''proceed if form was processed fine'' and ''give alert if some fields in the form were not correct''? If by ''proceed'' you mean refresh the page to display something else then I''d suggest you don''t need form_remote_tag. If by ''proceed'' you mean display some previously hidden form elements for the user to proceed entering more data, then you can use evaluate_remote_response for the :complete callback and return javascript from your action called by form_remote_tag. This javascript can then display the additional fields that need to be entered. You will know in the action whether or not you were passed valid data and so if not return different javascript that displays a hidden div containing an error message, or renders an error partial or alters the page in some other way to alert the user that invalid data was entered. You can do the above in combination with update_element_function in order to update multiple elements on a page if required. Maybe you could outline more of what you are trying to achieve and I might be able to help in more detail. Chris
On 8/24/05, Chris Roos <chris-zoUjy1rb4AnQXOPxS62xeg@public.gmane.org> wrote:> What do you mean by ''proceed if form was processed fine'' and ''give alert > if some fields in the form were not correct''? If by ''proceed'' you mean > refresh the page to display something else then I''d suggest you don''t > need form_remote_tag. If by ''proceed'' you mean display some previously > hidden form elements for the user to proceed entering more data, then > you can use evaluate_remote_response for the :complete callback and > return javascript from your action called by form_remote_tag. This > javascript can then display the additional fields that need to be > entered. You will know in the action whether or not you were passed > valid data and so if not return different javascript that displays a > hidden div containing an error message, or renders an error partial or > alters the page in some other way to alert the user that invalid data > was entered. You can do the above in combination with > update_element_function in order to update multiple elements on a page > if required. > > Maybe you could outline more of what you are trying to achieve and I > might be able to help in more detail. >Thanks Chris. I think that what you described is exactly what I need. If the form is not accepted, I want to highlight the fields that caused the problem, and if the submission was successfull, I want to hide the form and do other stuff with javascript. Thanks for the explanation! Raph