LSL HTTP server

From Second Life Wiki
Jump to navigation Jump to search


This is the counterpart to llHTTPRequest. While llHTTPRequest enables LSL scripts to request data from HTTP-accessible sources, HTTP-in enables outside sources to request data from LSL scripts in Second Life. The key difference is that llHTTPRequest exchanges data when the script in SL wants; HTTP-in allows outside sources to determine when they need to communicate with LSL scripts in SL.

Prior to HTTP-in, similar functionality could be achieved by polling with llHTTPRequest, llEmail and XML-RPC. All three are cumbersome and the latter two have serious scalability bottlenecks.

It is important to note that LSL HTTP servers cannot use llSetContentType with CONTENT_TYPE_HTML for an llHTTPResponse except in very limited circumstances. See Other Limitations for details.

This section forms the Incoming HTTP pipeline.


  • Easily get data from LSL scripts to outside viewers, LSL scripts or servers.
    • Web front end for a visitor counter or other statistics accumulator.
  • Easily get data into LSL scripts from outside viewers, LSL scripts or servers.
    • A store with a web front end that communicates to an in-world object to exchange L$ and inventory items.
    • Inworld game for which an external program handles the primary game logic that needs to manipulate inworld items.
  • HUD UI when used with llSetContentType. See HTML HUD Demo.

Gory Technical Details follow. Or jump straight to the Script Examples.

Script API


Event triggered when an URL is hit:
  • id is unique to this request
  • Supported methods are "GET", "POST", "PUT", "DELETE"
  • body: The body of the request.
Event also triggered with response to llRequestURL and llRequestSecureURL



Function: key llRequestURL( );

Requests one HTTP:// url for use by the script. The http_request event is triggered with the result of the request. HTTP-in uses port 12046.
Returns a key that is the handle used for identifying the result in the http_request event.


Function: key llRequestSecureURL( );

Requests one HTTPS:// (SSL) url for use by the script. The http_request event is triggered with the result of the request. HTTPS-in uses port 12043.
Returns a key that is the handle used for identifying the result in the http_request event.


Function: llReleaseURL( string url );

Releases the specified URL, it will no longer be usable.

• string url URL to release


Function: llHTTPResponse( key request_id, integer status, string body );

Responds to request_id with status and body.

• key request_id A valid HTTP request key
• integer status HTTP_Status (200, 400, 404, etc)
• string body Contents of the response.

The response need not be made inside the http_request event but if it does not happen in a timely fashion the request will time out (within 25 seconds).


Function: integer llGetFreeURLs( );

Returns an integer that is the number of available URLs.


Function: string llGetHTTPHeader( key request_id, string header );

Returns a string that is the value for header for request_id.

• key request_id A valid HTTP request keyA valid HTTP request key
• string header Lower case header value name

Returns an empty string if the header is not found or if the headers can no longer be accessed. Headers can only be accessed before llHTTPResponse is called and with-in the first 30 seconds after the http_request event is queued.

Generated Headers

These headers are automatically generated by the simulator, they were not actually sent by the requesting client. They supply information about the request to make parsing easier.

Sample URL:

header description example
"x-script-url" The base url, as originally received from llRequestURL/llRequestSecureURL
"x-path-info" Any trailing path information from the requested url /foo/bar
"x-query-string" Any query arguments, the text past the first "?" in the url arg=gra
"x-remote-ip" IP address of the host that made the request

Common Headers

header description example
"user-agent" The user-agent header as reported by the requester

llHTTPRequest Headers

Headers sent by the simulator in the course of calling llHTTPRequest.
Header Description Example data
connection Connection options close
cache-control Maximum response age accepted. max-age=259200
x-forwarded-for Used to show the IP address connected to through proxies.
via Shows the recipients and protocols used between the User Agent and the server. 1.1 (squid/2.7.STABLE9)
content-length The size of the entity-body, in decimal number of octets. 17
pragma The message should be forwarded to the server, even if it has a cached version of the data. no-cache
x-secondlife-shard The environment the object is in. "Production" is the main grid and "Testing" is the preview grid Production
x-secondlife-region The name of the region the object is in, along with the global coordinates of the region's south-west corner Jin Ho (264448, 233984)
x-secondlife-owner-name Legacy name of the owner of the object Zeb Wyler
x-secondlife-owner-key UUID of the owner of the object 01234567-89ab-cdef-0123-456789abcdef
x-secondlife-object-name The name of the object containing the script Object
x-secondlife-object-key The key of the object containing the script 01234567-89ab-cdef-0123-456789abcdef
x-secondlife-local-velocity The velocity of the object 0.000000, 0.000000, 0.000000
x-secondlife-local-rotation The rotation of the object containing the script 0.000000, 0.000000, 0.000000, 1.000000
x-secondlife-local-position The position of the object within the region (173.009827, 75.551231, 60.950001)
user-agent The user-agent header sent by LSL Scripts. Contains Server version. Second Life LSL/ (
content-type The media type of the entity body. text/plain; charset=utf-8
accept-charset Acceptable character sets from the server. Q being the quality expected when sending the different character sets. utf-8;q=1.0, *;q=0.5
accept Media types the server will accept. text/*, application/xhtml+xml, application/atom+xml, application/json, application/xml, application/llsd+xml, application/x-javascript, application/javascript, application/x-www-form-urlencoded, application/rss+xml
accept-encoding Acceptable content encodings for the server. deflate, gzip
host The internet host being requested.
  • CGI environments may place the headers into variables by capitalizing the entire name, replacing dashes with underscores, and prefixing the name with "HTTP_", e.g. "x-secondlife-object-name" becomes "HTTP_X_SECONDLIFE_OBJECT_NAME".
  • HTTP header names are case insensitive [1]. Some ISPs may modify the case of header names, as was seen in BUG-5094.

URL Lifetime Limitations

  • URLs are temporary!
  • URLs will be lost in the following cases, all detectable by the script events listed with them.
  • When urls are 'lost' it means that all public urls for that script are gone, new ones will need to be requested and the new urls will not resemble the old ones.
  • Maintaining persistent URLs will require building or using an external service similar to how Dynamic DNS services work for tying domain names to dynamic IP addresses.

Contributed HTTP-in URL mapping implementations and services:

Resource Limitations

  • There are a limited number of URLs available in each region, split by land ownership exactly like prim limits.
    • Use llGetFreeURLs to get the exact number of available URLs for the script.
    • The number of allowed URLs is the same as the number of allowed prims on the parcel the object is over.
      Object owner does not matter, all objects over a parcel will use the resource pool for that parcel.
      Like prims, all the parcels owned by the same owner and in the same region share the same pool of resources.
      If you have two parcels in a region that each support 100 URLs, then you could use all 200 in object(s) on a single parcel.
    • The region's object bonus factor does not apply to available URLs.
      If a parcel has a max of 300 prims in a region with a 2x bonus factor there will only be 150 urls allowed.
  • Each resident has their own unique pool of available URLs with a max of 38 URLs per resident.
    • This is 1 per attachment point, but all 38 could be used by a single attachment for example.
  • Vehicles are special and lazily moved to resident pools by the following logic:
    • Any object that has a resident sitting on it is a 'vehicle'
    • Vehicles will use the url resources from the parcel they are over until the cross a parcel border.
      Specifically this prevents anyone from breaking your vending machine by sitting on it and making it a 'vehicle'.
    • When any object using URL resources with a resident sitting on it crosses a parcel boundary the resources will switch to the first sitting resident with enough resources. If no sitting agents have enough resources then the resources from the parcel being moved onto will be used. If even then there are not enough resources to use then the vehicle will be blocked from moving.
      In short we do everything we can to find a pool to host the resources needed by the vehicle, but will block movement if we can't.
  • Parcel Sale: When a parcel is sold such that it changes the total available URLs in the region for either resident (seller or buyer) such that more URLs are being used than are available some objects will be returned.
    • The objects returned will be from youngest object to oldest object of those using URLs in each category in order of object category: Temporary, Other, Group, Owner, Selected/Sat upon.
      The only time objects are possibly returned is when parcels change owner, and only if more resources are being used than allowed.
      We return youngest temporary objects before older temporary objects before younger 'other' (owned by non-group, non-parcel-owner) objects etc.

Other Limitations