Go Back   SL Forums > Forum Archive > Archive > Preview 1.10.0 Feature Feedback
Welcome, Al Supercharge.
You last visited: 06-19-2007 at 12:26 AM
User CP GUIDELINES - please read before posting New Posts Quick Links Log Out

Thread Tools Search this Thread Display Modes
Old 04-22-2006, 06:34 AM   #1
Kermitt Quirk
Registered User

Join Date: Sep 2004
Location: Australia
Posts: 261
llHTTPRequest headers

This is a continuation of a conversation that been going on in the comments on the wiki page for [URL=http://secondlife.com/badgeo/wakka.php?wakka=llHTTPRequest]llHTTPRequest[/URL]. Hopefully more people will see it here and I can explain what I've been doing in more depth.

So where I'm trying to get to here is to be able to collect all the X-SecondLife headers from within Ruby. I've attempted with both Ruby and PHP and seem to only be able to get X-SecondLife-Owner-Name and X-SecondLife-Shard. I suspect I'm just looking in the wrong places for the info because before now I've never tried to do this in either PHP or Ruby so it's all new to me.

So first off, the php stuff. As Velox mentioned on the wiki this is only working in Cayman and Darkwood in 1.9.1 (13). In Morris a call to a php script returns a status of 415. I had already discovered the apache_request_headers() variable, but I don't have php installed as an apache module so unfortunately that doesn't work for me. I've been using phpinfo(INFO_VARIABLES) which probably wouldn't be any good for a real application but from my understand of that function it should still prove the point for the purposes of testing. In a test using that today I have managed to get the first 5 SL headers, but still can't find X-SecondLife-Local-Rotation, X-SecondLife-Local-Velocity, X-SecondLife-Owner-Name or X-SecondLife-Owner-Key. Possibly I'm hitting a limit on the return data here?

Because the return data in this case is HTML I'm just using a simple function like this to test if the headers were returned...
[PHP]findHeader(string body, string header) {
integer i = llSubStringIndex(body, header);
if (i != -1)
llWhisper(0, llGetSubString(body, i, i + 50));
So if body is the data returned in the body param of the http_response event, and I pass that "HTTP_X_SECONDLIFE" for header it returns...[HTML]HTTP_X_SECONDLIFE_SHARD"]
Testing [/HTML]
But passing it "HTTP_X_SECONDLIFE_OW" returns nothing.

Now for the Ruby stuff I'm just outputting the contents of the request.env hash. (BTW... llHTTPRequest still seems to work fine in Morris when calling Ruby instead of PHP) I've seen some Ruby sites referring to a variable called header (or maybe it was headers) that is supposed to have this info too, but that always seems to be empty for me. I think maybe request.env is the incoming headers, and the header var is outgoing headers for the response. So atm my Ruby code is a helper function that looks like this...
[PHP] def llHTTPRequestTest
returning html = '' do
@request.env.each do |header|
html << header[0] + "|"
html << header[1] + "|" if not header[1].nil?

This is resembling something that would be much more useful in a real app. It should return all the headers separated by pipes. At the LSL end I'm parsing that into a list and just dumping the whole lot to chat.
[PHP] headers = llParseString2List(body, ["|"], []);
integer headersLength = llGetListLength(headers);
integer i;

for (i = 0; i < headersLength; i += 2) {
string name = llList2String(headers, i);
llWhisper(0, name + " = " + llList2String(headers, i + 1));
The output I get from this combination is...

OK..... I've just answered my own question. I already had it further up the post in fact. The return data is indeed being truncated. The body is never longer than 512 bytes. I changed my Ruby code to the following and got the whole lot back (although I still hit the 512 char limit so I think it's still dropping a handful of chars at the end)
[PHP] def llHTTPRequestTest
returning html = '' do
@request.env.each do |header|
if header[0].include? "HTTP_X_SECONDLIFE"
html << header[0] + "|"
html << header[1] + "|" if not header[1].nil?

So I guess this raises a new question. Is this a limit of llHTTPRequest, or is it something to do with HTTP in general? Would there be any way to get the rest of the data?

Sorry bout the mammoth post, but I'm sure this will be useful for others, so I'll post the whole thing anyway. Thanx again to Velox Severine for your help with this so far.
Kermitt Quirk is offline Report Bad Post  
Old 04-22-2006, 02:48 PM   #2
Milo Linden
Quality Assurance

Join Date: Mar 2006
Location: UK
Posts: 140
Hi kermit

Thanks for the post, some very interesting information, the problem with http we only recently found when we got upgrated hardware on preview, is that it wasnt working on the new class 4 sims, in preview thats most of the mainland, but if people want to test they can try it on most of the private islands that are up which are running on class 3's

Interesting to know that ruby still works on the class 4 hardware.

I'll ask around about the body size limits, you could try playing with the HTTP_BODY_MAXLENGTH and see if there is a default and a maximum.

Milo Linden is offline Report Bad Post  
Old 04-22-2006, 04:22 PM   #3
Velox Severine
Network Slave

Join Date: May 2005
Location: S. Colorado, United States
Posts: 73
Send a message via AIM to Velox Severine Send a message via Yahoo to Velox Severine
I haven't tried it in, but in my last test HTTP_MIMETYPE and HTTP_BODY_MAXLENGTH were currently unavailable. Testing...

Okay, I was able to retrieve 2049 characters from a site ([url]http://www.joyofpi.com/pi.html[/url]) regardless of the method (which suggests POSTing data does not subtract from the return). HTTP_BODY_MAXLENGTH is still an unrecognised parameter, as well as HTTP_MIMETYPE. When I sent 11kb of data, it POSTed the entirety of it. It appears to send as much data as you can possibly send in a script (which is ~16k or less depending on script size and current data, so before the script has a stack/heap collision).


Inbound - 2049 bytes
Outbound - Available free memory in script

Not sure about rate-limiting, or blacklist time yet, as a Linden has not posted that information to the LSL wiki or the forums yet.

llHTTPRequest appears to have no sleep.

Last edited by Velox Severine : 04-22-2006 at 04:31 PM.
Velox Severine is offline Report Bad Post  
Old 04-22-2006, 06:04 PM   #4
Zero Linden
Linden Lab Employee

Join Date: Oct 2005
Posts: 22
Hiho all -

Later this weekend I'll put / correct some details in the LSL wiki. I'll add all the exported headers.

The observations about the options not being supported yet are true. And the limits are as discovered. We intend to keep them that way: Outbound from the script - as much as you can throw at it. Inbound to the script, for now, capped at 2048. Note that you should get an indication that your input was truncated in the metadata list in the http_response event.
Zero Linden is offline Report Bad Post  
Old 04-24-2006, 08:18 AM   #5
Kermitt Quirk
Registered User

Join Date: Sep 2004
Location: Australia
Posts: 261
Still a bit confused about why I'm only seeing 512 chars in the response then. Something to do with the encoding used maybe? I'm only getting 512 characters in the body string, but I guess that doesn't necessarily mean that only 512 bytes of data were returned.
BTW... the metadata received in this situation contains 0 and 2048, so the 2048 would make more sense now. Is the zero just indicating that the return data started at position zero?
Kermitt Quirk is offline Report Bad Post  
Old 04-24-2006, 08:03 PM   #6
Harris Hare
Second Life Resident

Join Date: Nov 2004
Posts: 301
You are correct Kermitt. The body string returned is limited to up to 2049 bytes. When I spoke with Milo in the preview grid, he said that because character sets differ, 512 characters is a typical maxium number of characters to expect back but not an exact number to expect.

While Milo was careful not to give out any details of what the threashold of the "allowed request rate" is (for good reason), I did pose him some hypotethicals. For example, I have a device I'm building that will fire off about 30 requests to the same host with each request taking about 1 second. Then it stops. He said that shouldn't be a problem. He also said that any object that makes a single request every couple of minutes all the time are perfectly fine (ie. current song annoucers). Also, if it wasn't already obvious, the request originates from the simulator machine where the script is running and is independant of agents.

Finally, he said that rate-limiting will be done on a PER USER basis (not per object). How far that exceeds is speculative. It could mean that all scripts owned by that user in the same sim would no longer be allowed outbound requests for a set amount of time... or that all scripts everywhere owned by that user would be not longer be allowed outbound requests for a set amount of time.

I think he said that if the system does determine you're abusing, that your outbound requests are ignored (and return NULL_KEY to the event) for only a few minutes.

Sorry if I put any words in your mouth Milo. All this is from memory of our conversation over a week ago.

Last edited by Harris Hare : 04-24-2006 at 08:14 PM.
Harris Hare is offline Report Bad Post  
Old 04-24-2006, 08:48 PM   #7
Argent Stonecutter
Multiple Body Disorder

Join Date: Sep 2005
Posts: 5,868
The per user outbound limits mean you have to be very careful how you use this call for product security, because someone could bust their per user limit, then do something with the object you sold them, and you wouldn't receive an announcement on your webserver.

This could be an inadvertant DOS on the user, or it could be conceivably used to cheat on games and gambling devices.

Doesn't mean you can't use it, of course, just means you need to be aware of the possibility and make sure it fails cleanly.
Argent Stonecutter is offline Report Bad Post  
Old 04-24-2006, 08:53 PM   #8
Milo Linden
Quality Assurance

Join Date: Mar 2006
Location: UK
Posts: 140

You sure it was me you talked to?

I really dont know what the limits will be, i've not had time to look it up yet, too busy sorting and verifying the bug queue lol

Milo Linden is offline Report Bad Post  

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is On
Forum Jump

All times are GMT. The time now is 04:41 AM.

Powered by: vBulletin Version 3.0.5
Copyright ©2000 - 2007, Jelsoft Enterprises Ltd.
Copyright 2002-2007 Linden Lab