| ||||||||||||||||
|
|
Welcome,
Al Supercharge. You last visited: 06-19-2007 at 12:26 AM |
|
Thread Tools | Search this Thread | Display Modes |
04-22-2006, 06:34 AM | #1 | ||
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)); }[/PHP] 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] If I pass it "HTTP_X_SECONDLIFE_L" I get...[HTML]HTTP_X_SECONDLIFE_LOCAL_POSITION"] |
(113[/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? end end end[/PHP] 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)); }[/PHP] 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? end end end end[/PHP] 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. |
04-22-2006, 02:48 PM | #2 |
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. |
04-22-2006, 04:22 PM | #3 |
Network Slave
|
I haven't tried it in 1.9.1.13, 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). Limits- 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. |
04-22-2006, 06:04 PM | #4 |
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. |
04-24-2006, 08:18 AM | #5 |
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? |
04-24-2006, 08:03 PM | #6 |
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. |
04-24-2006, 08:48 PM | #7 |
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. |
04-24-2006, 08:53 PM | #8 |
Quality Assurance
Join Date: Mar 2006
Location: UK
Posts: 140
|
Mmm 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 |