LSL HTTP server/fr

/fr

/LSL

Introduction

Les fonctions de serveur HTTP en LSL sont le pendant de llHTTPRequest. Alors que llHTTPRequest permet aux scripts LSL de Second Life de récupérer des données sur des sources accessibles en HTTP, ces fonctions entrantes HTTP permettent à des sources externes de récuperer des données depuis des scripts de Second Life. La différences principale est que llHTTPRequest échange des données au moment désiré par le script dans SL, alors que les fonctions entrantes HTTP permettent à des sources externes de déterminer à quel moment elles ont besoin de communiquer avec des scripts de SL.

Avant les fonctions de serveur HTTP, on pouvait obtenir un résultat équivalent en consultant à intervalles régulier avec llHTTPRequest, llEmail et XML-RPC. Les trois solutions étaient lourdes et les deux dernières avaient du mal à monter en charge.

Applications

• Fournir aisément des données depuis des scripts LSL à des navigateurs SL, des scripts ou des serveurs externes.
  • Interface web pour un compteur de visiteurs ou un autre outil statistique
• Injecter aisément des données dans des scripts LSL scripts depuis des navigateurs SL, des scripts ou des serveurs externes.
  • Un magasin avec une interface web qui communique avec un objet du monde pour échanger des L$ et des éléments de son inventaire.
  • Un jeu dans le monde où la logique de jeu principale est prise en charge par un programme externe qui doit manipuler des éléments dans le monde.

Si vous ne voulez pas vous plonger dans les détails techniques qui suivent, allez directement voir les exemples de scripts.

Interface de programmation

• key llRequestURL()

Demande une nouvelle URL publique de serveur LSL.

Un évènement http_request se déclenchera que cela échoue ou réussisse et contiendra la clé renvoyée.

Code LSL : request_id = llRequestURL(); 

• key llRequestSecureURL()

Semblable à llRequestURL mais demande une URL HTTPS / SSL.

Un évènement http_request se déclenchera que cela échoue ou réussisse et contiendra la clé renvoyée.

Code LSL : request_id = llRequestSecureURL(); 

• llReleaseURL(string url)

Libère l'URL indiquée, Utilisé à la fois pour les URL normales et sécurisées.

Code LSL : llReleaseURL("http://sim123.agni/cap/f23b4b94-012d-44f2-bd0c-16c328321221");

• http_request(key id, string methode, string corps)

Évènement déclenché quand une URL est appelée :

• id est unique à cette requête ;
• Les méthodes prises en charge sont GET, POST, PUT et DELETE ;
• corps : le corps de la réponse.

Évènement également déclenché en réponse à llRequestURL et à llRequestSecureURL

• id correspond à la clé renvoyée par llRequestURL et llRequestSecureURL
• methode vaut URL_REQUEST_GRANTED en cas de succès et URL_REQUEST_DENIED en cas d'échec à obtenir une URL
• corps est l'URL publique. S'il a été impossible d'obtenir une URL publique, corps sera vide.

• llHTTPResponse(key id, integer etat, string corps)

Envoie corps au demandeur avec le code d'état etat

• id iest l'identifiant id reçu dans l'évènement http_request correspondant à la requête en question

• string llGetHTTPHeader(key id, string entete)

Renvoie une chaîne contenant la valeur de l'entête indiqué dans la requête indiquée

• Les en-têtes reconnus sont :

• "x-script-url" : l'URL de base, telle qu'elle a été reçue au début par llRequestPublicURL
• "x-path-info" : tout le chemin mentionné dans l'URL demandée
• "x-query-string" : tous les arguments de type interrogation, c'est-à-dire le texte suivant le caractère ? dans l'URL
• "x-remote-ip" : l'adresse IP de la machine qui a fait la requête
• "user-agent" : l'entête user-agent envoyé par le demandeur

requested url: https://sim123.agni/cap/f23b4b94-012d-44f2-bd0c-16c328321221/foo/bar?arg=gra
x-script-url: https://sim123.agni/cap/f23b4b94-012d-44f2-bd0c-16c328321221
x-path-info: /truc/machin
x-query-string: arg=hop

• changed(integer change)

• CHANGED_REGION_RESTART : l'évènement changed() est à présent déclenché quand la région redémarre.

• integer llGetFreeURLs()

Renvoie le nombre d'URL disponibles pour le script.

URL Lifetime Limitations

• URLs are temporary!
• URLs will be lost in the following cases, all detectable by the script events listed with them.
  • On object derez/rez: on_rez
  • On script save/reset: default state_entry() (trickier in multi-state scripts)
  • On region cross or TP(attachments): 'changed() event, CHANGED_REGION and CHANGED_TELEPORT
  • On region restart: changed() event, new flag CHANGED_REGION_RESTART
• 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.

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.
• 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.

Liens

• Exemples de scripts
• Document conceptuel
• JIRA du concept:SVC-1086