Strangest llHTTPRequest bug EVER

I ran across this one today testing a new script. The script itself makes 3 llHTTPRequest() calls... the problem arrises with call #2

Call 1 works fine, call 3 works fine, call 2 returns the following


Now the really freaky part about it is.... normally the script works. It works 100% of the time mostly everywhere in SL.

The problem is that in a VERY few sims (Think i've noted 3 so far, out of about 50) that the script's 2nd http request returns the above error.

Any ideas? Dunno if I found a specific sim code bug or what

can you post part of the LSL script? That might be part of the problem. Otherwise it just looks like a permission issue on the web server.

its not the permissions on the webserver (remeber the script works fine in 99.9% of the sims tested)

code part? ya sure, its simply a llHTTPRequest() call


// http request #2
requestid = llHTTPRequest("http://www.somewebsite.com/somfile.php",[HTTP_METHOD,"POST",HTTP_MIMETYPE,"application/x-www-form-urlencoded"], "somedata=something&somedata=somethingelse";



i really dont think its the code or the webserver... it all works flawlessly except in a few very limited strange circumstances

I wouldn't think it would actually be a permission issue, I just meant that what info you gave made it look that way.

Anyway, you might try using the llEscapeURL() function for the variables. One of the variables in the POST data could possibly be containing something that is causing something to malfunction. You can unescape them with php then.

hmmm... well its a suggestion work trying perhaps. I didnt think of that. Its a post send method so I didnt really think it woulda mattered as there are spaces in the CSV data already. I will give a shot at it and post my results

my understanding is that POST data needs to be encoded also, double check to see if at the other end it comes through encoded still, it's been a while but iirc the webserver usually unencodes POST data before it passes it to the script.

that wasnt it...

what it IS, is that for some reason or another... certain key combinations in SL make the database put in corrupt data.... even with llEscapeURL() to escape the csv list....

im looking further into it now... looks like it needs corrected on the PHP side

If you don't mind, post back what you find. I'd be interested in case I run into this problem.

i still have no idea what it is.... llEscapeURL prevents the 403 error, but for some reason the datas still not getting received correct. ILl look into it more later when i have time

try this? http://us3.php.net/mysql_real_escape_string