GET shouldn't be used for any request that modifies the server state (anything with 'set' in its name, for a start). GET is only for information *retrieval*, and has to be safe and idempotent (RFC2616, 9.1).
I understand this can't be changed now for compatibility reasons, but at least all mutating requests should accept POST (in addition to GET for compat.) and should only mention POST in the documentation. Same for the website. Any place that uses url_tokens() is likely wrong. If you need to use CSRF protection tokens, chances are that request is supposed to be POST anyway. A possible exception is logout; and again I quote people smarter than me: "i don't dock people for not having csrf tokens on logout. logout is a failsafe -- it can suck if it gets csrfed, but it's better than something going wrong and the session staying open". -- Nicolás 2012/5/26, David Anderson <[email protected]>: > Willy: > I implemented this (just for am_set_info) > and deployed it on SETI@home. > Please test it if you can; I didn't test it. > Also let me know if you need a POST version of other RPCs. > -- David > > On 26-May-2012 12:44 AM, Willy wrote: >> I'm now hitting a limitation with the web RPCs. With certain RPC's the >> input is too large for the HTTP GET which is then ignored by the server >> (Error: Request-URI Too Large. The requested URL's length exceeds the >> capacity limit for this server.). >> >> Especially http://boinc.berkeley.edu/trac/wiki/WebRpc#am_set_info is a >> problem because it's used to set preferences. >> >> My suggestion is to also allow HTTP POST. >> >> To work around the problem I limited the number of venues send to the >> server. >> >> Willy. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
