LSL http server old

Goals

Create an alternative to the XMLRPC server for communication with LSL scripts initiated from outside Second Life that is easy to use and scalable.

Design

LSL

• llRequestHTTPServerURL()

An asynchronous event with no return data.

This will create a capability on the cap server that maps to an internal simulator url.

An http_event will be triggered with type 'SERVER_URL' and a body of the cap url created.

If a cap already exists for this object, the existing URL will be passed to the http_event

One server/url per prim.

Example public url: https://sim123.agni.lindenlab.com/cap/f23b4b94-012d-44f2-bd0c-16c328321221

• llClearHTTPServerURL()

This will clear or invalidate the cap for this lsl http server.

Calling llRegisterHTTPServer again after this should generate a new cap URL.

Triggers an http_event with success/fail. (or just always with 'success' if it is not possible to fail)

Automatically called on object/script death/return/deletion. (what about script state being set to 'not running'?) Timeless Prototype

• http_server(string method, list meta, string body)

Event triggered when an URL is hit.

• method is GET/POST/PUT/DELETE
• meta is a list of meta data about the request.
  • Initially this is only REQUESTING_HOST which is the IP of the request. This can be extended later as needed.
• body is the body of the request

• http_event(integer type, string body)

Triggered for specific events relating to the HTTP server

• SERVER_URL: body will be the cap url that maps to this scripts http server
• URL_LOST: no body, triggered whenever a cap is lost or cleared
  • urls will be lost if the object changes regions or the region restarts

Questions / Issues

• Should these caps time out?
• Can we make the cap server pass along everything after the cap itself to the simulator and the script?

This idea has been revisited several times in the last year and devs. keep deciding that data on the URL after the cap should be dropped. It makes for the most certain security. Zero Linden 14:37, 16 November 2007 (PST)

If we decide we can do this later we can pass the remainder of the url in with the meta data - Kelly

• Define mime-handling

I believe that we should, like the llHTTPRequest() call, be very clear in our handling of bodies and mime-types. In particular, accept only text/* mime types, and be sure to do proper charset handling and conversion into the UTF-8 that LSL strings use. (The code should all be cullable from the llHTTPRequest() implementation.) Zero Linden 14:37, 16 November 2007 (PST)

Performance Requirements

This should add no database, assetserver or viewer load.

Simulator:

• In general load should be no higher than existing alternatives (xmlrpc, llEmail and llHTTPRequest) for any single action.
• Connections need to be throttled.

It would be nice if this could happen before the simulator on a per-cap basis, but throttling in the simulator handler would probably work as well.

TODO:

• Get statistics on # of XMLRPC connections, llHTTPRequests and llEmails per unit of time per region to set expectations for level of usage.
  • XMLRPC: We start to see failures at ~300 concurrent XMLRPC requests across 2 servers (~150 / serveR). We have seen peaks at ~300 concurrent requests, we sit around 50 - 60 total concurrent requests normally now.

Security Impact

Creating a server accessible in any way from outside needs to be done with care. The cap server already does this, and security concerns should already be handled here. This isn't something to take for granted though.

• Scripts should be allowed to use llHTTPRequest to contact the cap server, care needs to be taken in this interaction.

Limitations

• Size of the body of the requests and maybe the size of responses will need to be limited. At least to something that will fit within script memory - 2k is probably right.

Why not have this user configurable via function? One size does not fit all. - Strife Onizuka

This size limit is partially for performance reasons. We can not support large requests and large responses at a large scale. A configurable max size just doesn't make any sense, we should figure out the max size we can support and set that as the max. If people use less, then they use less. - Kelly Linden

• Incoming requests will need to be throttled at some rate. Script event queuing acts as a throttle for what connections the script will be able to handle, but that probably isn't enough. I would guess that near the rate of llHTTPRequest throttling is probably good - ~1 / second / object.

Can we throttle before we reach the sim? - Kelly

Interactions

• Relies on capabilities and the cap server
• Effects LSL development including MONO