Odd error message returning whta i think is UUID

[Gregory McLeod]

I am debugging a complex HUD script which communicates with a website.

The script sends a POST to the web page correctly and gets a response. The status returned is 200. The body however does not contain the expected "*OK" or "*UPD" so it sends a message to the owner, me, which says

HUD Server Error: cap not found: '4baaf270-e135-eff9-da91-a2d5a422620a'

This latter part would seem to be a UUID but I cannot identify it. I have looked for anything named 'cap' but not found anything.

Is there a way of identifying whatever was not found using the UUID?

If I can identify that I can then check what is missing and supply what is missing.

[Darkie Minotaur]

Does the PHP script try to get the information to be passes back to the script that notifies you by means of http in? It seems to me that the messages you get is the message that SL sends you if http in gets an request for an outdated URL of an object.

[Gregory McLeod]

Thanks for the reply.

Yes it does and I have tried to decipher the PHP script that is invoked by the LSL script in the HUD. It Opens a file in the public_html folder on the server and that does contain a string which could be the problem. That string reads

http://sim10156.agni.lindenlab.com:12046/cap/54604be4-4538-c807-80b7-3a26b11c7140/

which possibly identifies the cap portion of the error message I quoted. The error seems to be a file or folder not found.

I am still looking for a method of identifying the unknown UUID.

[Darkie Minotaur]

You can't. If I remember right, it's the uuid of the http-listener, as it where.Once the mapping is lost, the http-listener is lost

[Gregory McLeod]

Thanks again,

I have tackled this problem from a different angle. From other LSL scripts I have detected that one of the functions obtains a URL for use by external sources. This is communicated to the webserver PHP script which is supposed to update the data file with the URL and which includes the port number so that the PHP script can send a request for the LSL script on ereceipt can give inventory to the requesting avatar. Something seems to be going wrong with that updating so I am trying to find out what.

Back to the depths of PHP.

[Darkie Minotaur]

What you describe sounds sensible.

1. Object in SL requests an URL
2. LSL script in this object sends the URL to a web server where a PHP script stores the URL to some kind of DB (mySQL, text file)
3. PHP retrieves the URL from the DB
4. PHP sends a request to the object using tis URL

Somewhere along this workflow, the URL sent to the PHP gets outdated - reasons could be: The DB contains old URLs e.g. the URL does not get updated, or an old URL doesn't get deleted ... The object gets rerezzed (e.g. because it gets tped) but the URL doesn't get updated. The object gets deleted without deleting the URL from the DB.

Keeping the URLs of a complex system updated can get pretty painful.

[Ohjiro Watanabe]

I don't know if this is a clue for you but may be of interest:

 

https://www.sloodle.org/moodle/mod/forum/discuss.php?d=3655

[Gregory McLeod]

I have never heard of sloodle.org and don't click on strange links.

[Gregory McLeod]

@Darkie

That is what I believe is the correct process. The problem is that I am the only user of the test website I have setup and the saved information as you suggest gets saved with a serialize and save data to file.

I think I have spotted my mistake in the analysis of the error.

It raises an interesting question if the httprequest is

gkRequestID = llHTTPRequest(gsUpdateURL,[HTTP_METHOD,"POST",HTTP_MIMETYPE,"application/x-www-form-urlencoded"],lsOptions+"&au="+llMD5String(lsOptions+"#"+gsGameKey,giGameNonce));

Can this be generated from a browser so I can check the effect of the different parts

http://website/a../b../c../d...php?op=hudcheck&ui=c337c075%2D0527%2D4684%2Db65b%2D94b6ddeaa0e6&ve=0%2E9%2E9%2E6&au=b21a99479bdccf6f27e8cbed01eab4dd

Does not work I think because the & after the d..php is not the correct format.

What is?

[Rolig Loon]

---

Gregory McLeod wrote:

I have never heard of sloodle.org and don't click on strange links.

---

You are wise.  In this case, however, sloodle.org is a safe, well-respected site, so you're OK.  It's been used by educators in SL since well before I started here in 2007, and it has a lot of cool stuff on it.  :smileywink:

SLOODLE is a free and open source project which integrates the multi-user virtual environments of Second Life® and/or OpenSim with the Moodle™ learning management system.

SLOODLE provides a range of tools for supporting learning and teaching to the immersive virtual world; tools which are fully integrated with a tried and tested web-based learning management system used by hundreds of thousands of educators and students worldwide.

[Darkie Minotaur]

I do not fully understand, what you want to do in that test.

If you send an URl from a browser, it gets encoded - I guess that's what you refer to when you're saying "not the correct format" - PHP usually handles that automatically.

[Gregory McLeod]

Thanks for the reply.

I am sorry if I was not clear in my aims. To enable me to check that the correct response is coming from the PHP script in the server I wanted to be able to test it using a simple browser. Entering http://a.b.c/d.php followed by parameters which emulate or simulate what the llHTTPRequest assembles from a request such as

gkRequestid = llHTTPRequest(gsUpdateURL,[HTTP_METHOD,"POST",HTTP_MIMETYPE,"application/x-www-form-urlencoded"],lsOptions.....

where the lsOptions contains op="validate&ui="+llEscapeURL((string)gkPlayer)+"&ve="+llEscapeURL(gsHUDVersion);

I am making it clearer?

 

[Darkie Minotaur]

Let me see if I get you right:

• you call an php from a browser - http://myserver.com/sample.php
• the call should include GET parameters like:  http://myserver.com/sample.php?para1=1&para2=2
• these parameters get passed by the php by CURL or fopen to a SL object that has a valid URL

Where exactely does your problem with the character encoding happen?

[Gregory McLeod]

OK we seem to be on the same wavelength now.

In a hud script there is the following line

gkRequestID = llHTTPRequest(gsUpdateURL,[HTTP_METHOD,"POST",HTTP_MIMETYPE,"application/x-www-form-urlencoded"],lsOptions+"&au="+llMD5String(lsOptions+"#"+gsGameKey,giGameNonce));

In the lines that precede that are lines that set the values for the gsUpdateURL, and the lsOptions.

In the quoted line is a standard way of obscuring and authenticating the content should it be intercepted (the portion startng with &au=). the gsGameKey and giGameNonce are also set as fixed values although in the real HUD they are dynamically set.

I want to use  a browser to verify the actions by the gsUpdateURL which is a PHP script which interprets the various parts of the value/pairs OP=??? and au=??? which are detected from the $_POST array variables in the PHP script..

So if I type in the browser url field

http://gsUpdateURL.php?op="somevalueofactionoperand"&au="somevalueofoperand" I get a 404 page not found when I expected a response from the server and that is what is bugging me.

Any ideas?

NB I now know that what I thought was a UUID is infact the url of the receiving HUD in a SL region !

[Darkie Minotaur]

if you get a 404 error, there is something wrong with the URL. Does the request from the script get through?

Another thing (which shouldn't be directly related to the 404 error) is that the if you send the parameters after the URL like you seem to do (i.e. starting with a ? after the URL), this will result in a GET request - whereas in the LSL script you use a POST request.

I would think that the parameters that you type into the browser contain elements that result in a malformated URL. Let the LSL say the URL and the parameters - then copy and paste theser elements to the browser. This way you can make sure, they are encoded correctly. This should get rid of the 404 error - but it won't get you the result wanted, since you still have the GET vs. POST issue.