Tested with the latest master and it seems like the status and body is working properly now. The script now runs correctly when there is no error and acts upon status codes correctly if there is an error.

Many thanks Justin! :)


On 7/8/2013 9:50 PM, Chris M wrote:
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) <[email protected]>
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)

_______________________________________________
Opensim-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users

Reply via email to