User:Void Singer/Teacup

From Second Life Wiki
< User:Void Singer
Revision as of 08:23, 19 April 2011 by Void Singer (talk | contribs) (Major upgrade for version change)
Jump to navigation Jump to search


What is it?

Teapot is an open source webserver front end for LSL's HTTP-in + MOAP functionality. It builds on the work of several other people including but not limited to, Kelly Linden, Torley Linden, Tali Rosca, Vegas Silverweb, and special mentions to Kate and/or Edelman Linden. The idea is to make it easy to serve web content from within SL, with a minimum of work or understanding, in the most standards compliant and flexible way possible.

How does it work?

Externally, when Teacup starts, it gets a URL and creates a Micro HTML page, which it bootstraps onto the prim face with a "data:" URN. Once loaded, that page requests a JavaScript library, which loads normally. Once loaded, the library bootstraps the specially prepared ".tsp" HTML content onto the current page, and captures all links targeting other ".tsp" pages, so that it can do the same when they are requested. Internally the server broadcasts a message when it gets a page request, and any installed File Service scripts can reply with content, or the server will simply report back that it doesn't have the file requested if it doesn't receive a reply in a set time.

Why all the tea jokes?

Well I happen to like steam punk stuff, and it has a sort of pseudo-Victorian-era feel to it, but in all truth it was sparked by a bit of geek humor. There was an old april fool's joke passed around as an official sounding memo about creating a protocol for controlling coffee pots with HTTP (back before they actually started making net enabled appliances) and part of that proposal was that teapots should return an error response 418 "I'm a teapot" if you tried to make it brew coffee... since these servers are small, and 418 is safe to use internally because it wouldn't normally be encountered, I figured hey, Teapot --> Teacup --> Victorian Imagery --> Steam Punk --> teacup that is it's own teapot --> SIP --> many different types of tea --> Success!

... And thus was born the SIP, Teacup server, and Red Tea File Service
(developers are encouraged to keep the theme, but it's not a requirement)

Return to top

Quick Start

So you don't want to read a bunch of tech babble, you just want to make a website in a prim right? Well I can sympathize so here are some (mostly) easy steps to get you up and running fast...

  1. Rez a box and name it something creative, like "My website"
  2. Follow the instructions on This Page or choose a File Service from the Compatible File Services and Extensions and follow those instructions.
  3. Copy the text in the grey box below Code: Saucer into a script named "Saucer v0.3", save it, and drop it in your rezzed box
  4. Copy the text in the grey box below Code: Teacup into a script named "Teacup v0.3", save it, and drop it in your rezzed box
  5. Click on the top of your box if your webpage isn't already showing.
    • At this point you may want to rotate and/or resize your box.
    • If you like, you have my express permission to download (right click, "save as") and edit (with whatever image editor you like) the Teacup.png file to use as the default texture of your website prim.
  6. Show it off to your friends with MOAP enabled viewers

If you run into any problems, simply start a thread with the problem you are having here, and I or some other technical wizard will assist you.

Return to top



  • Save in a script named "Teacup"

<lsl>/*( Teacup Server v0.3 )*/

//-- stores the entire bootstrap or error page for touch handling string gStrErr0 = "data:text/html;charset=utf-8, <html>


Out of Service

Url Interface Unavailable or a Server script failed to respond

Teacup/Saucer v0.3
<a href='secondlife:///app/agent/"; string gStrErr1 = "/about'>Contact Owner</a>



//-- pending request queue for pages waiting to be served //-- this (hopefully) prevents reponding after SL send a timeout. list gLstPndKey; list gLstPndTim;

key gKeyRqs; integer gIntRqs;


        //-- Request URL on start up
   on_rez( integer vIntBgn ){
        //-- Clear pending and request URL on rez
       gLstPndKey = gLstPndTim = [];
   changed( integer vBitChg ){


This section is not required reading for users, it is really only of use to scripters looking understand of extend it.

Server Protocols

File Requests

The server communicates it's needs in the following format <lsl>llMessageLinked( LINK_SET, REQUEST_CODE, REQUEST_PAGE, REQUEST_KEY );</lsl>

  • LINK_SET: Request is broadacst to all prims (exception, the root page "" is requested in the local prim only)
  • REQUEST_CODE: at this time, for simplicity, there is only one request code, 418
  • REQUEST_PAGE: the format is [<page name>?<search string>]
    • this will be extended for POST pages, format is undecided at this time
  • REQUEST_KEY: the return key for the requested data.
    • NULL_KEY and a page name of " Server Start" will be sent when the server file availability handler resets.

Server Notes

  • The server takes the site title from the Prim name it's in
  • The hovertext of the prim the server is in will contain it's base address (invisibly)
  • The Server is 2 scripts (Teacup & Saucer) and 2 default files (teacup.js & teacup.css)
    • The default files require a File Service (Like Red Tea) to load
  • The Server includes a quick 404 handler to prevent missing or unknown files from slowing down page loading. It accepts some special commands listed below in the "File Service Protocol: Advanced" section. Any unknown page received with a 200 code for a pending request will automatically be added to the known list.

^ Return to top

File Service Protocol


File Services receive data via link messages, in the following manner <lsl>link_message( integer REQUEST_SOURCE, integer REQUEST_CODE, string REQUEST_PAGE, key REQUEST_KEY )</lsl> File Services should minimally check that REQUEST_CODE is 418 (file request), and that REQUEST_KEY is a valid key to confirm it's a valid server request.

REQUEST_PAGE can be parsed with <lsl>list vLstPage = llParseStringKeepNulls( REQUEST_PAGE, ["?"], [] ); //-- The page name will be contained in: llList2String( vLstPage, 0 )</lsl>

If the page name is NOT a page that this File Service handles, it should do nothing. Otherwise it should return it's data in the following format: <lsl>llMessageLinked( REQUEST_SOURCE, RESPONSE_CODE, FILE_TEXT, REQUEST_KEY );</lsl>

  • REQUEST_SOURCE: the link number that the server request came from.
  • RESPONSE_CODE: one of the following integer values (they are all normal HTTP RESPONSE CODES)
    • 200 (Success: default value, can be used for anything that returns content)
    • 201 (Created: optional alternative, probably best if the file was created for the request)
    • 202 (Accepted: optional alternative, probably best for commands that generate in world actions)
    • 204 (No Content: optional alternative, probably best for form data, FILE_TEXT should be blank)
  • FILE_TEXT: text of the file that was requested.
  • REQUEST_KEY: server request key for this file.
Any return should be done within 20 seconds or it's results will be ignored.


There are two style in which a File System can behave. Passive, and Active. Active is preferred.

Active File System services should advertise each file as soon as it's available using

File Added: Sent when file is available in the file system<lsl>llMessageLinked( LINK_SET, 22, "name of the file", NULL_KEY ); //-- key MUST be the constant NULL_KEY</lsl>

When a file is removed from the file system it should send

File Removed:Sent when a file is removed from the file system<lsl>llMessageLinked( LINK_SET, -22, "name of the file", NULL_KEY ); //-- key MUST be the constant NULL_KEY</lsl>

Additionally, if and Active File System receives the " Server Start" message (418 code, plus " Server Start" text, and NULL_KEY), it should resend "File Added" for each of the files still available, but no faster than 10/second for file system.

Alternatively, if the file system can respond to normal requests in under 2 seconds, any file that is sent with response code 200 will automatically be added, and those would not need to be sent.

Passive File Systems do not need to advertise their available files, but if they receive a request that they might reasonably expect to take more than 2 seconds to fill, they should immediately send

File Exists (Continue): Sent to prevent a 404 message for a file from slow passive file system elements. <lsl>llMessageLinked( REQUEST_SOURCE, 100, "", REQUEST_KEY );</lsl>

and then follow up with their normal response. the 20 second return limit is still in effect.

Passive systems should NOT use response code 200, or if they do, MUST send "File Removed" messages when the file is removed. Use codes 201, 202, and 204 instead.

^ Return to top

Teacup Server Page (".tsp") Format

Teacup serves a modified html page called a Teacup Server Page (.tsp), to overcome limitations in the LSL HTTP-in behavior.

if a requested filename ends with ".tsp" it needs to conform to a specific format that is similar but not identical to the contents of a normal html webpage. To convert an html page into a tsp page, the follow actions must take place (an example of all of them may be found in the Red Tea file system.
  • The file name should end with ".tsp" (Teacup server page)
  • The contents are limited to what's valid inside a normal html "body" tag.
  • It also requires the following minor changes, made in order:
    1. all backslash characters must be converted to double backslashes (may be applied on a line by line basis)
    2. all single quote characters must be prefixed with a backslash (may be applied on a line by line basis)
    3. all line breaks should be converted to "\n" literals (may be applied on a line by line basis)
    4. The page should be prefixed with "vTea='" and suffixed with "';" (applies only to the whole page)
      • eg:
         file_string = "vTea='" + file_string + "';";
Return to top


Compatible File Systems and Extensions

Red Tea - A very simple File Service System for a starting point.

Known Bugs

  • inline script/style elements are not evaluated at load time (inline attributes should work normally)
    • images have their own events, and can be used to trigger page load javascript
  • document/body onload events are not triggered for .tsp pages
    • images have their own events, and can be used to trigger page load javascript
  • Fails to load on external browsers (jira pending)
    • This is a viewer problem right now, some of the internal browsers will load it
      • Phoenix will not load it in the internal browser, because they limit the webkit address field to 255 characters, I'm going to see if I can't work around this with cramped formatting, or get the phoenix devs to work on it
      • v2 viewers should load the index page fine to the internal browser. if you copy the address and paste it into an external browser it will work from there
        • confirmed on Firefox 3.6, unknown on any others at this time.

Requested Feature Upgrades

  • Add handling for POST action
    • Accepted: would like feedback on how to handle this internally though.
  • Add support per page javascript and css
  • Trigger at least the normal load events manually
  • Find a simple way to serve base64 encoded content such as images or sounds.
    • NEED ASSISTANCE: I can (probably) do it the same way we load pages, but this makes it hard for page writers.
  • Find a convenient way to set title on per page basis... probably use the page name
    • Accepted: Page titles should match the internal file name minus the ".tsp" extension

Change Log / Old Versions

Most Recent Changes are at the top, old version links below.

  • Teacup/Saucer v0.3
    • Server Test Page moved to saucer file availability handler
    • Server javascript page loader library (Teacup.js) moved to File Service System
      • Users should have less trouble editing the file now and can include their own functions in the same file
    • Sitewide CSS supported via Teacup.css
    • Saucer Script now handles page availability for quick 404 returns to speed page loading.
    • Site Title is pulled from the object name
    • Site address is discoverable by object scripts in the (hidden) prim hovertext
    • Server now runs from any prim, not just the root.
  • Teacup v0.2
    • Initial Public Release


I have kept this page as a sub page of my user page to denote that it should NOT be edited except to correct errors, add confirmed bugs, or add related resources.
The intent is to ensure executive control is in one person's hands to retain a cohesive vision of it's development.
If you have an improvement suggestion, or request, please use the discussion page.

Return to top

Questions or Comments?

Feel free to leave me a note on the discussion page.