Talk:LSL HTTP server

I believe one of the worst-case scenarios from XML-RPC today is the InnerLife / Mandala Web Temple architecture. Last I experimented (with an early format) we got stable results at 4 second intervals (this was back in mid-2006); We wanted faster (not enough for a proper biofeedback interface) so most dropped the project. Be aware that we wanted something that could be sustained for long intervals (3-4 hours straight, possibly with multiple avatars contributing toward 'merged' results). I'm not certain what the current request load is today, you can check with 'Carlos Tapioca' in-world as he is still actively perusing this. I'll also direct him here. Alan Kiesler 22:42, 6 April 2008 (PDT)

URL_REQUEST_TIMEOUT

I think there should be a URL_REQUEST_TIMEOUT method. That way the script has a chance to catch the event and send the user some meaningful information before the connection actually cut. A user could have two scripts, one that handles the HTTP serving while the other gathers data. If the data gathering sends the data as it receives it then the HTTP script can cache the data and when it receives all of it or the timeout is thrown it can send the data it has. If the script misses the window on the connection and the event was queued then it should be dequeued and not triggered. -- Strife Onizuka 16:53, 16 May 2008 (PDT)

- There are no plans for such an event. Requests will time out which will send a timed out error / status (504 Gateway Timeout) to the requester. Events are a scarce resource in LSL, also anything that lets you do 'one last thing' before a time out either creates a time out loophole or is already too late. If you find your requests are frequently timing out you will need to adjust your code to return smaller result sets more frequently. - Kelly Linden 10:55, 13 June 2008 (PDT)

HTTP_STATUS_*

Might be beneficial to have HTTP_STATUS_* code constants. -- Strife Onizuka 20:34, 16 May 2008 (PDT)

- Specifically which codes do you want defined this way? I'd like to keep the number of constants to a minimum, would _OK (200), _MISSING (404) and _ERROR (500) be enough? - Kelly Linden 10:47, 13 June 2008 (PDT)

Those sound good. -- Strife Onizuka 11:42, 13 June 2008 (PDT)

Should have one for that evil Linden error 499 (for use with the llHTTPRequest side of things). -- Strife Onizuka 23:30, 16 June 2008 (PDT)

robots.txt

Do we want google spidering the caps urls? -- Strife Onizuka 20:34, 16 May 2008 (PDT)

- This is a good point, and probably not. - Kelly Linden 10:56, 13 June 2008 (PDT)

Payload Size Limits / Content

Will the data payload size be similar to the current http_response limits? And will we be able to implement something like reverse http with it?

Thanks,

BlueWall <j>

- There will be payload size limits for PUT and POST, and a max lengh for x-untrusted-argument. And no, you will not be able to implement something like reverse http. There is no provision for 'upgrade' and requests time out rather quickly (<25 seconds) which will make any long poll mechanism difficult - Kelly Linden 15:10, 17 June 2008 (PDT)

Content-Type

What about the content-type and more importantly charset? Will it be utf-8? Are URLs in utf-8? Is it "text/plain; charset=utf-8" then? - Thomas Shikami 20:31, 16 June 2008 (PDT)

- Yes, responsees will be "text/plain; charset=utf-8". We will attempt to transcode the body of POST and PUT actions to UTF-8 before they hit the script. URLs will be url encoded - including the 'x-untrusted-argument' which will remain url encoded until (if) the scripter uses llUnescapeURL. - Kelly Linden 15:01, 17 June 2008 (PDT)

I vote for a mechanism to set the response content-type arbitrarily (except the charset, where UTF-8 is fine). If worried about arbitrary response content-types, perhaps the initial implementation could limit the allowable content-types to the set ["text/plain","text/xml","application/json", ...]. Then a future implementation could expand the allowed types without changing the function API.

Consequently, it would also be useful to be able to accept "text/xml", "application/json" and perhaps others.

In order to discourage phishing, the implementation could automatically set the response content-type to text/plain if the user agent sent identifies any of the major web browsers (IE/Mozilla/Webkit..). - Cenji Neutra 08:09, 16 July 2008 (PDT)

Landowner only usage?

• Not all requests for an url will succeed, the scripter is expected to handle the failure case.
• The number of available urls will be based on the amount of land owned in the region

As the majority of my work is placed on land I don't own, does this mean I'm going to be in "last place" when it comes to getting URLs? And if it fails, am I then left to using XML-RPC and email again? Seems pointless to build this in if I still need to have the script set up the other systems, with their associated timers and failsafes. Also, what kind of limits are we talking about per sim? I'm thinking of a rental system I made with approx 40-50 rental units on a sim. Each one would need to be updated from the web - and http in would be perfect, but only if the limits make it feasible and reliable. ~~ Hippyjim Starbrook‎ 15:37, 15 July 2008 (PDT)