[Opensim-users] Strange error on master when using llHTTPRequest on master

[Chris M]

Hi Justin, I ran git bisect and came up with these results:

831e4c38506140e9ece2db4b96b4f0960a0276a8 is the first bad commit
commit 831e4c38506140e9ece2db4b96b4f0960a0276a8
Author: Justin Clark-Casey (justincc) <jjustincc at googlemail.com>
Date:   Thu Apr 4 00:36:15 2013 +0100

     Fix bug where outstanding llHTTPRequests for scripts were not being 
aborted
when they were deleted.

     This was because AsyncCommandManager was handing an item ID to 
IHttpRequestM
odule.StopHttpRequest() rather than the expected request ID.
     This commit also makes the http request asynchronous using 
BeginGetResponse(
) rather than doing this by launching a new thread
     so that we can more safely abort it via HttpWebRequest.Abort() 
rather than a
borting the thread itself.
     This also renames StopHttpRequest() to StopHttpRequestsForScript() 
since any
  outstanding requests are now aborted and/or removed.

:040000 040000 59b8f81dde66f9861e72ea7797e8e23237c106d5 
1fbf0bf11f4dff0e91df079e
912dbf539b9f8cbc M      OpenSim

Also posted a mantis for it here 
http://opensimulator.org/mantis/view.php?id=6704 in case it was needed :)

Thanks!

On 7/8/2013 5:15 PM, Justin Clark-Casey wrote:
> Hi Chris.  This is very likely an unintentional regression.  I would 
> suspect an unintentional change in ScriptsHttpRequest.cs since that 
> introduces a 499 on certain exceptions, though on a quick look I don't 
> see anything obvious since it should be passing through genuine 
> protocol errors.
>
> I should think this behaviour change was introduced later than 3611d33 
> (Mon Mar 18 22:04:27 2013) since the immediately following changes are 
> unrelated to http (being attachment changes).  As ever, bisecting this 
> change to a specific commit would be extremely helpful.
>
> On 07/07/13 01:42, Chris M wrote:
>> I believe I may have stumbled across the issue; it seems that in the 
>> http_response(key id, integer status, list meta,
>> string body) event, status always contains 499 and body always 
>> contains "The remote server returned an error: (status
>> code) Some string" instead of the actual status number and the string 
>> sent back in body by the server I'm connecting to
>> as expected on LL grid and on OS 0.7.5
>>
>> For example, If I put llSay(0, (string)status + llUnescapeURL(body)); 
>> in my script I see this: "499 The remote server
>> returned an error: (404) Not Found." instead of "404 NOTFOUND: 
>> Missing item name here" "NOTFOUND: Missing item name
>> here" is the string  in body from the database server.
>>
>> I can parse the string to extract the the correct status code with this:
>> list temp = llParseString2List(llUnescapeURL(body), ["The remote 
>> server returned an error: ", "(", ")"], []);
>> integer new_status = llList2Integer(temp, 0);
>>
>> and proceed from there.
>>
>> The "NOTFOUND: Missing item name here" string sent back in body by 
>> the database server is lost though (whether I extract
>> the status code from the string or not), and the script depends on 
>> that information to determine what wasn't found, and
>> act accordingly to it.
>>
>> Was this change in how the status codes are handled intentional?
>>
>> I apologize if the entire explanation seems confusing and/or long 
>> winded; but this was a very confusing thing for me to
>> try to write out :)
>>
>> On 7/2/2013 8:53 PM, Chris M wrote:
>>> Hello all, I have a roleplay HUD that I scripted that uses 
>>> llHTTPRequest to query an external database server for
>>> usernames and profiles and then use that data to configure the HUD 
>>> accordingly.
>>>
>>> On the latest master I'm encountering a strange message in chat that 
>>> I'm not sure what to make of:
>>> 499 The remote server returned an error: (300) Ambiguous Redirect.
>>>
>>> The database server console seems to be getting the request and 
>>> sending the data back... but no data seems to be
>>> received by the HUD and it fails to configure the HUD.
>>>
>>> On commit 3611d33 (r/22387) it all works fine and as expected with 
>>> no errors.
>>>
>>> Unfortunately that is all the info I can think of to give; but is 
>>> anyone seeing this as well?
>>
>>
>
>


-- 
OpenSim: 10 Region Standalone on 0.7.6 Dev
Physics: Open Dynamics Engine
OS: Windows 7 (x64)
CPU: AMD Phenom II X4 840 3.2 GHz
Memory: 11 GB DDR3
Database: MySQL 5.1.63 (x64)