The HTTP server functionality described in http://wiki.secondlife.com/wiki/LSL_http_server makes it very difficult to host a stable server object in SL. This is because the script must allocate a new temporary URL not only for new object instances, but also if the script is reset, if the sim is restarted, or if the object changes regions. An obvious solution to this problem would be to use the key of the prim to form a URL. This should work because there is already a need to lookup an object by key on the grid (otherwise even in-world object-to-object e-mail wouldn't work). Speed for HTTP functionality might be an issue, but if LL is serious about implementing this kind of feature, some form of efficient caching could be implemented. This also shouldn't be any more onerous than registering a temporary URL as is currently done for beta. However, then the question is, "Which script would service any given request if multiple have http_request handlers?" An event-based solution is much more desirable than some kind of polling, not to mention necessary for both performance and to avoid HTTP timeouts, so a llGetNextEmail() type solution is out. I suggest using a URL that includes both the key of the prim and the URL-encoded name of the script (since a script name is unique within the inventory of its containing prim). Whether the script would still have to request the URL or whether it would be assigned automatically if the script has a http_request handler in the current event is a separate issue and could be addressed elsewhere. This would allow a script to determine its own URL using a simple pattern, llGetKey(), and 'llEscapeURL(llGetScriptName())'. Example URL pattern: http://lslwww.secondlife.com/<primKey>/<urlEncodedScriptName> Example URL: http://lslwww.secondlife.com/12341234-1234-1234-1234-123412341234/My%20Http%20Script IMPORTANT IMPLEMENTATION NOTE: There is nothing about this solution that would need to break existing beta scripts utilizing the functionality, except for the corner case where a script might request multiple URLs (which can be switched to using different path parts or query parameters to handle the same requirement). If the server logic always returns the calculated URL when a URL is requested, any scripts utilizing a single URL can continue to function as-is.