Talk:LlHTTPResponse

Resetting (recte: clearing) The query string?

Ok, I'll bite.... why would you need to do this? I get the freeing up the memory taken by a key, buy you shouldn't be checking the the uuid anyways, but rather what the method was used, to determine what to do with the data. if anything you should be tracking the uuid returned in case you aren't returning a response in the llHTTPResponse event (and if you are, there's no need to track it outside the event)
-- Void ^{(talk|contribs)} 00:46, 10 October 2012 (PDT)

I dunno what the editor's exact reason(s) are, but I think it's always good practice to reset any key you're no longer using as there is that tiny, tiny chance of the same key being used again. I do agree though that the method should really be checked first, as in theory there could be a future method that won't have a key (e.g - some kind of information event that is triggered automatically, rather than being requested), in which case the example would try to send a reply that may not have a destination, aside from that it's good practice to restrict behaviour to only the method(s) you expect to receive. Also, I personally think it's generally good practice to reset keys to NULL_KEY rather than an empty string; I know that for a single value it doesn't matter much but if you use a lot of keys then they can add up, and you should really keep the memory "reserved" so you're not using memory that you think is free, unless you know the variable is never going to be used again, but in that case you should be trying to eliminate it =)
-- Haravikk ^{(talk|contribs)} 02:13, 10 October 2012 (PDT)

As Haravikk said, I reset it cause I'm not using it anymore. On another note, why would you reset rather to NULL_KEY in this particular case? Say you set params for llHTTPRequest with [ HTTP_VERBOSE_THROTTLE, FALSE ] ...and you exceed the request max rate and only get NULL_KEY's back for request key?
--unsigned comment by Kireji Haiku ^{(talk|contribs)} 02:47, 10 October 2012 (PDT)(please sign comments, thanks ;)

My honest thought here is that in this example there's no reason to capture the request key at all (I honestly have no clue why they bothered to include a return for it in llRequestURL, since release uses the actual address, and no other key can be captured except within the event.). at that rate something like this would be much cleaner and simpler demonstration of the function... <lsl>default{

   state_entry(){
       llRequestURL();
   }

   http_request( key id, string method, string body ){
       if (~llListFindList( [GET,POST,PUT,DELETE], [method] )){
           llHTTPResponse( id, 200, "Body of request below:\n" + body );
       }else if (URL_REQUEST_GRANTED == method){
           llOwnerSay( "URL: " + body + "/" ); //-- might want to add that slash, SL servers require it.
       }else if (URL_REQUEST_DENIED == method){
           llOwnerSay( "Something went wrong, no URL.\n" + body );
       }
   }

}</lsl>
-- Void ^{(talk|contribs)} 02:33, 21 October 2012 (PDT)