Difference between revisions of "LSL HTTP server"

From Second Life Wiki
Jump to navigation Jump to search
m (moved LSL http server to LSL HTTP server: HTTP is capitalized)
m
Line 1: Line 1:
{{LSL Header|ml=*}}
{{LSL Header|ml=*}}
== Intro ==
== Introduction ==
This is the counterpart to [[llHTTPRequest]].  While llHTTPRequest lets scripts in Second Life request data from HTTP-accessible sources, this HTTP-in enables outside sources to request data from 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 scripts in SL.
This is the counterpart to [[llHTTPRequest]].  While llHTTPRequest enables LSL scripts request data from HTTP-accessible sources, HTTP-in enables outside sources to request data from 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 scripts in SL.


Prior to HTTP-in, similar functionality could be achieved by polling with [[llHTTPRequest]], [[llEmail]] and [[:Category:LSL_XML-RPC|XML-RPC]].  All three are cumbersome and the latter two have serious scalability bottlenecks.
Prior to HTTP-in, similar functionality could be achieved by polling with [[llHTTPRequest]], [[llEmail]] and [[:Category:LSL_XML-RPC|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 HTML. See "Other Limitations" for more details.
It is important to note that LSL HTTP servers cannot use HTML. See [[#Other_Limitations|Other Limitations]] for details.


== Uses ==
== Uses ==
Line 12: Line 12:
* Easily get data into LSL scripts from outside viewers, scripts or servers.
* Easily get data into LSL scripts from outside viewers, scripts or servers.
** A store with a web front end that communicates to an in-world object to exchange L$ and inventory items.
** A store with a web front end that communicates to an in-world object to exchange L$ and inventory items.
** A game in-world where the primary game logic is handled by an external program which needs to manipulate in world items.
** Inworld game for which an external program handles the primary game logic that needs to manipulate inworld items.


Gory Technical Details follow.  Or jump straight to the [[LSL_http_server/examples | Script Examples]].
Gory Technical Details follow.  Or jump straight to the [[LSL_http_server/examples | Script Examples]].

Revision as of 11:50, 5 November 2009

Introduction

This is the counterpart to llHTTPRequest. While llHTTPRequest enables LSL scripts request data from HTTP-accessible sources, HTTP-in enables outside sources to request data from 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 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 HTML. See Other Limitations for details.

Uses

  • Easily get data from LSL scripts to outside viewers, scripts or servers.
    • Web front end for a visitor counter or other statistics accumulator.
  • Easily get data into LSL scripts from outside viewers, 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.

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

Script API

Request a new LSL Server public URL.
An http_request event will be triggered with success or failure and include the returned key

<lsl>request_id = llRequestURL();</lsl>

Similar to llRequestURL except requests an HTTPS / SSL URL.
An http_request event will be triggered with success or failure and include the returned key

<lsl>request_id = llRequestSecureURL();</lsl>

Clear the specific URL, used for both secure and non-secure URLs.

<lsl>llReleaseURL("http://sim3015.aditi.lindenlab.com:12046/cap/3ff4f3f2-ea08-76c1-cef6-a22b4a573a7c");</lsl>

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
  • id matches the key returned by llRequestURL or llRequestSecureURL
  • method == URL_REQUEST_GRANTED for success, URL_REQUEST_DENIED for failure to get an URL
  • body is the public URL. If unable to get a public URL body will be empty.
Send body to the requester with status code status
  • id is the id from http_request that maps to the specific request
  • sending a response to the requestor will clear the request and delete information associated with it
Returns the string for the specified header in the specified request. All received headers are converted to lower case and this function is case-sensitive. The returned string is limited to 255 characters.
  • Supported headers are:
  • "x-script-url": The base url, as originally received from llRequestURL or llRequestSecureURL.
  • "x-path-info": Any trailing path information from the requested url
  • "x-query-string": Any query arguments, the text past a ? in the url
  • "x-remote-ip": IP address of the host that made the request
  • "user-agent": The user-agent header as reported by the requester
  • "x-secondlife-shard"
  • "x-secondlife-object-name"
  • "x-secondlife-object-key"
  • "x-secondlife-region"
  • "x-secondlife-local-position"
  • "x-secondlife-local-rotation"
  • "x-secondlife-local-velocity"
  • "x-secondlife-owner-name"
  • "x-secondlife-owner-key"
requested url: https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322/foo/bar?arg=gra
x-script-url: https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322
x-path-info: /foo/bar
x-query-string: arg=gra
This header information is valid for 30 seconds, or until llHTTPResponse is called.
Returns the number of URLs available to this script.

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

  • Size of the body of the requests will be limited to 2k bytes.
  • Size of headers of requests will be limited to 255 bytes. This is per header, not total.
  • The size of responses to requests is not currently limited, but this is subject to review during testing.
  • The content type of the returned data is always 'text/plain; utf-8'
    Allowing more content type options is a possibility for the future, but not guaranteed.
  • There is a cap of 64 in flight requests per script. This is based on the maximum number of pending events in LSL.
  • We may throttle the rate we accept hits at the CAP server level as well. This is possible, but has not yet been decided.
  • HTML cannot be used without an external parser, as all output is plain text only. If making such a parser, remember that you should probably restrict access to only Linden Lab HTML URLs as to not have your bandwith stolen.
  • It is important to note that when appending a query string to a cap URL there MUST be a trailing slash between the cap guid and the query string token '?'. IE https://sim123.agni.lindenlab.com/cap/f73b4b94-012d-44f2-bd0c-16c328321221?arg=gra will return an HTTP 500, but https://sim123.agni.lindenlab.com/cap/f73b4b94-012d-44f2-bd0c-16c328321221/?arg=gra will succeed.

Links

Retrieved from "https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server&oldid=647103"