Jump to content

Http_response: How does the page need to be formatted for PHP to SL functionality


Valareos
 Share

You are about to reply to a thread that has been inactive for 4070 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Ive been looking all over the wiki and the interent to find some examples of this, but cant find what im looking for.

In specific I need an example of how the HTTP page is formatted before SL parses it.  I know there are free scripts that take care of it, but i need something specialized that i have to make from scratch

If i know how to display php generated page that SL reads, I can figure out the rest! Thanks

Link to comment
Share on other sites

it is data being trasferred from an sql database via php webpage parsed by http_response.  Those responses are stored as variables to be used.

 

I doubt i can just format the page anyway I want, as I would think the http_response would be looking for a specific layout to match ids with values. feel free to correct me if i am mistaken on how it works!

Link to comment
Share on other sites

right... so can pull header info as variables for web side, adding in any post information passed via SL, parse it, then make a reply back with imbedded Post Information for SL to look back up and use.

 

Thanks for the help!

Link to comment
Share on other sites

Ok.. this is what i have so far as proof of concept (making sure i work out any bugs in syntax and such)  php page only purpose is to take info from SL, and give back the database reference. it also adds the person to the list if they not already there

Here is the script in SL

key requestid;string get_post_value(string content, string returns){    list params =  llParseString2List(content,["&"],[]);    integer index = ~llGetListLength(params);     list keys;    list values;     while (++index)    {        list parsedParams =  llParseString2List(llList2String(params, index), ["="], []);        keys += llUnescapeURL(llList2String(parsedParams, 0));        values += llUnescapeURL(llList2String(parsedParams, 1));    }     integer found = llListFindList(keys, [returns]);    if(~found)        return llList2String(values, found);        return "";}default{    http_response(key request_id, integer status, list metadata, string body)    {        if (request_id == requestid)            {               llSay(0,"Hello, " + get_post_value(body,"Username"));            }    }    touch_start(integer x)    {        string param = "UUID=" + (string)llDetectedKey(x-1) + "&Username="+ llDetectedName(x-1);        requestid = llHTTPRequest("*** MY URL ***",             [HTTP_METHOD, "POST",             HTTP_MIMETYPE, "application/x-www-form-urlencoded"],            param);    }}

 And here is the PHP side

<?*** DB INFO REMOVED ***$db = mysql_connect(DB_HOST, DB_USER, DB_PASS);mysql_select_db(DB_NAME, $db);$user = $_POST['Username'];$uuid = $_POST['UUID'];if(empty($user)){	echo "error";}$sql = "	SELECT *	FROM `user`	WHERE `UUID`='$uuid'";$result = mysql_query($sql);if (!$result){}$row = mysql_fetch_array($result);$name = $row['Name'];if(empty($row['UUID'])){	$sql2="		REPLACE INTO `user` (`UUID`,`Name`)		VALUES ('$uuid','$user')	";	$result2 = mysql_query($sql2);	if (!$result2){		echo 'Could not run query: ' . mysql_error();		exit;	}	$name = $user;}echo "UUID=$uuid&Username=$name";mysql_close($db);?>

 A few questions.. have i done anything that requires me to release a url?

Link to comment
Share on other sites

It looks ok as a proof of concept.

There is nothing to release - releasing an URL only matters in cases where you request an rL for your object, so you can send a request to it (often called "HTTP in"). You do HTTP out and thus don't need an URL for your object (and don't request one).

I know that it is just a proof of concept, but you may consider the following:

  • Use PDO  insted of just the mysql_* commands - it comes with a number of advantages
  • If UUID is the primary index of your table (which would make sense, since you want every ava to be in  it just once), you could use INSERT IGNORE to prevent getting an error each time an ava already is in the table  without doing the SELECT first. 
  • For all string data you're sendind to the webserver, you should do an llEscapeURL - it will keep you from looking for some strange errors
  • Like 1
Link to comment
Share on other sites

Mysqli will be faster than PDO. You can see more benchmarks online that prove this as well as : http://jonathanrobson.me/2010/06/mysqli-vs-pdo-benchmarks. You may find tests that may prove the reverse. Though it is a very known truth that Mysqli is faster. Just PDO nuts try to invalidate with convoluted methods to testing. Don't believe me and do your own reading. Its nicer in the long run anyways.

Mysqli is still currently more stable than PDO. Anyone needing proof should have experience to know this, or look it up on the web for more information.

And concerning how the majority of users in SL need a functional system over a OOP with some flare. It really is better to stick to Mysqli. If anyone says PDO is more secure, you can do the very same with Mysqli its a moot point. You aren't designing for the U.S. government. So trying to structure code like a tank that only ever runs over a rubber ducky. Is a bit silly and unneeded. People should inquire to the applicability of the end means before the designation of a given path.


Just a random simple script.

 

string URL="https://www.somewebsite.net/myphp.php?";
list http_parms = [HTTP_METHOD,"POST",HTTP_MIMETYPE,"application/x-www-form-urlencoded"];

key http;
list sendData=[];

process(){
        integer len=llGetListLength(sendData) & 0xFFFE; // make it even
        string body;
        
        integer i;
            for (i=0;i<len;i+=2){
                string k=llList2String(sendData,i);
                string v=llList2String(sendData,i+1);
                    if (i>0) body+="&";
                    body+=llEscapeURL(k)+"="+llEscapeURL(v);
            }
        
        http=llHTTPRequest(URL,http_parms,body);
        sendData=[];
}
 
default {
    
    touch_start(integer num){
        integer points = 1234;
        sendData = ["points",points];
        process();
    }
    
    http_response(key id,integer status, list meta, string body){

        if(http==id){
            integer i;
            list lbody=llParseString2List(body,["\r\n","\n"],[]);
            integer count=llGetListLength(lbody);
             
            if(status == 200){
                for(i=0;i<count;i++){
                    llSay(0,"["+(string)i+"] "+llList2String(lbody,i));
                }
            }

        }
    }

}
Link to comment
Share on other sites

I don't really think that yout post  is a reply to the post - but still interesting. As far as PDO vs. MySQLi is concerned, I stick with the authot of the page you quoted. He wraps up:

" In my opinion, the features and flexibility of PDO far outweigh the very slight performance hit."

And I absolutly agree that there are a range of factors, that influence how you should/could design your application. As far as OOP is concerned, I agree, too. But that hasn't even been mentioned here.

Link to comment
Share on other sites

-nods- Just giving my two cents as it were. Though I guess in the end it really is, as you say, subjectable to means. Speed and stability is often a bigger factor for me. And with Mysqli that is very true over PDO. Someone else may opt for something else. I would still say that should be a prefered even for SL. Because when is a novice or standard user going to really try and take full advantage of PDO, and its offerings? I just wouldn't suggest using PDO unless I knew exactly what the end means was for. Where Mysqli may be sufficiently used in its stead. If you forgive the analogy. Its like saying you want to drive 1 meter in a Ferrari, when you could have walked it. Its the same -groan- feeling I get when someone compiles a script in Mono when all it does is say "Hello World". There is a reason why scripts can still be saved in both formats. And always reasons for why one may be used over another. And really from what I see of the request I see very little need currently for PDO.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4070 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...