If you allow both, could you make it so that of for the same parameter a
POST and a GET is available, you use the POST.

Reason: it will take some time (maybe never) until all projects have
updated to this new code. Until then I can send a POST request which still
has most of the parameters in GET as well (just not prefs). Otherwise I
would have to send a POST, check if it succeeded, if not send a GET.

Willy.

On Sun, May 27, 2012 at 9:24 AM, David Anderson <[email protected]>wrote:

> The new version (once I debug it) will allow either POST or GET.
> -- David
>
>
> On 27-May-2012 12:23 AM, Willy wrote:
>
>> Getting "500 Internal Server Error" now, even when I do not use POST but
>> GET.
>> Send the same request to PG, no error.
>>
>> Gives me time for questions:
>> * Did you change all the parameters to POST?
>> * Do you still allow GET (thinking about other AMS which would need to
>> upgrade
>> otherwise) and if so, which has precedence, POST or GET?
>>
>> Willy.
>>
>>
>> Willy.
>>
>> On Sat, May 26, 2012 at 11:54 PM, David Anderson <[email protected]
>> <mailto:[email protected]**>> wrote:
>>
>>    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<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] 
>> <mailto:boinc_dev@ssl.**berkeley.edu<[email protected]>
>> >
>>
>>     > 
>> http://lists.ssl.berkeley.edu/**mailman/listinfo/boinc_dev<http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev>
>>     > To unsubscribe, visit the above URL and
>>     > (near bottom of page) enter your email address.
>>    ______________________________**_________________
>>    boinc_dev mailing list
>>    [email protected] 
>> <mailto:boinc_dev@ssl.**berkeley.edu<[email protected]>
>> >
>>
>>    
>> http://lists.ssl.berkeley.edu/**mailman/listinfo/boinc_dev<http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev>
>>    To unsubscribe, visit the above URL and
>>    (near bottom of page) enter your email address.
>>
>>
>>
_______________________________________________
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.

Reply via email to