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