Talk:LlHTTPRequest
Please sign your comments when replying!
Headers
The following headers will be present, usable by scripts running on the HTTP server if the scripting language allows you to access the headers.
An PHP example on how to check to see if the call came from the main grid:
<?php
if ($_SERVER["HTTP_X_SECONDLIFE_SHARD"] == "Production") {
echo 'You are using the main grid';
} else {
echo 'You are not using the main grid';
}
?>
—The preceding unsigned comment was added on 10:52, 9 May 2007 by Zeb Wyler
Does POST work?
I have a Question .. Does POST work ? I couldnt get it working Anylyn Hax — 13:34, 28 July 2007 (PDT)
Odd format for header names
Why are the headers listed as HTTP_SOME_HEADER_NAME, when the sent headers are in the format Some-Header-Name? Is there some benefit to putting false values that match conventions used by CGI, but aren't actually correct? - Katharine Berry 09:55, 21 June 2007 (PDT)
- This is because you are looking at a global property with a lot more information than just headers. Some functions like listed below handle the stripping of the HTTP_ information, but you could also just use substr to remove the HTTP_ Wouter Hobble - 4 July 2008
I am aware that the example given above works, but (assuming that you're using mod_php) this would too, and reflects the real header names:
<?php
$headers = apache_request_headers();
if($headers['X-SecondLife-Shard'] == 'Production')
{
print "You are on the main grid.";
}
else
{
print "You are on a preview grid.";
}
?>
Additionally, the current information does not show the capitalisation, thus further confusing the matter. Katharine Berry 09:55, 21 June 2007 (PDT)
Root Certificates
Can someone add a list of root certificates to this article?
I know that Verisign, Thawt, and RapidSSL are accepted, I know that CACert.org is not. —The preceding unsigned comment was added on 09:18, 27 April 2008 by Ahroun Maelstrom
HTTP_VERIFY_CERT behavior clarification
Even when HTTP_VERIFY_CERT is set to FALSE, if the certificate domain name does not match the URL domain you will get a HTTP 499 response. —The preceding unsigned comment was added by Apotheus Silverman
- That does not sound like a bug. That sounds like a feature. If I tried to access https://www.microsoft.com and the certificate was for hax0r.com I would be thinking there was a man-in-the-middle attack happening. On the flip side if you don't verify the signing authority you can pretend to be anyone you want. I don't know which is worse, the false sense of security or certificate impersonation. -- Strife (talk|contribs) 13:21, 15 October 2008 (PDT)
Region limit
Besides the 25/sec/script limit there is some limit per time per REGION. Error Message "This region currently has too many in progress HTTP requests." so what is it?—The preceding unsigned comment was added on 05:08, 27 December 2008 by Ollj Oh
I am totally confused
I gulp a stare. I hope it makes sense to me one day. -- Eddy (talk|contribs) 15:55, 10 June 2009 (UTC)
POST?
I Could Not Get Post To Work To A PHP page, It Was Picked Up By The Page As A Get.
llHTTPRequest(url, [HTTP_METHOD, "POST"], "");
Post, Put, And Get All Came Across As Get On The Server. So Does HTTP_METHOD Not Work? — Adi 19:48, 20 August 2009 (UTC)
References to forum threads are now broken
The references to threads in the now closed old forums (re caveat on throttling) are now broken; LL have indicated that (at the time of writing) it will be four weeks until the archives are available. I've added a comment to this effect on the page, but perhaps someone knows a better way to handle this. Pete Olihenge 10:09, 16 February 2010 (UTC)
The forum archives have come online. But it doesn't look like you can search them by thread number (which is used in the original URL) and as I have no idea what the original threads were called, I can't see any way of updating the broken links. Pete Olihenge
HTTP 302 Redirects not being followed
I POST form data to my server which in turn redirects me sending an HTTP 302 status code which does not seemed to be followed as it says in the Wiki. Any comments? Epilort Byrne 17:05, 1 March 2010 (UTC)
- After my experiments I would say it only follows GET requests --Kuraiko Yoshikawa 01:59, 11 May 2010 (UTC)
- RFC2616 §10.3.3 prohibits the "user agent" (llHTTPRequest, in this case) from following a 301 or 302 automatically:
- "If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued."
- If you want the user agent to GET another URL after your POST, you should send a 303 status code back, with the desired URL. (I'm not sure if llHTTPRequest understands 303s, however.)
- --Pauline Darkfury 10:57, 18 July 2011 (PDT)
HEAD is also a valid HTTP_METHOD
Or at least it functions by retrieving the header when used, which makes llGetHTTPHeader an odd inclusion. —The preceding unsigned comment was added on 02:15, 13 November 2024 by Pazako Karu
Question about default MIME header values
According to the page, the default values for the MIME encoding/accept requests is always "text/plain; charset=utf-8", which makes a lot of sense to me, since the main usage of this request will be, indeed, to use it to connect to APIs (as SL cannot do much with HTML anyway — at least, at the time of writing, although doing funky things with 
SMIL used to be possible, for writing plain text dynamically on prim textures set to Media).
However, as of late March 2025, I came across some APIs that can emit plain text, JSON and/or XML errors; or HTML as a fallback. It looks like SL internally prefers to get HTML in the responses. Previously, using the default settings for llHTTPRequest, everything worked as intended, that is, when the request was made in plain text, it would always receive plain text as an answer.
Might it be the case that LL has changed the defaults to be */*, i.e., "accept anything", which is common/usual for browsers, for example? This would be a breaking change for many pure, plain-text APIs, specifically made for SL, at the time before LSL had JSON support. One wonders, therefore, if, these days, LL thinks that "accept anything" makes more sense, so that APIs answering with JSON as the preferred option (which, indeed, is true for most cases) will pass as intended, without the user needing to remember to explicitly ask for a response in JSON.
But this is just a conjecture, I'd need more data to be sure of what I'm claiming. Unless, of course, some friendly resident here has stumbled upon the issue before, and can update this page, with confidence, that these are, indeed, LL's new defaults.
— Gwyneth Llewelyn (talk) 09:26, 30 March 2025 (PDT)