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 changement)

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

Limitations de la durée de vie des URL

• les URL sont temporaires !
• les URL seront perdus dans les cas suivants, qui peuvent tous être détectés au moyen des évènements mentionnés en face.
  • Lorsque l'objet est empoché, puis rezzé : on_rez
  • Lorsque le script est enregistré ou réinitialisé : default state_entry() (plus dur à gérer dans les scripts multi-états)
  • Lors du changement de région ou de téléportations (attachements) : 'évènement changed(), drapeaux CHANGED_REGION et CHANGED_TELEPORT
  • Lorsque la région redémarre : évènement changed(), nouveau drapeau CHANGED_REGION_RESTART
• Quand les URL sont "perdues", cela signifie que toutes les URL publiques pour ce script ont disparu, il faut en demander de nouvelles, et les nouvelles URL ne ressembleront pas aux anciennes.
• Pour disposer d'URL persistantes, il faut développer ou utiliser un service externe semblable dans leur fonctionnement aux DNS dynamiques, qui lient quant à eux des noms d'hôtes à des adresses IP dynamiques.

Limitations en ressources

• Le nombre d'URL disponibles dans chaque région est limité, il est divisé en fonction de la surface du terrain exactement comme les limitations en prims.
  • llGetFreeURLs donne le nombre exact d'URL disponibles pour le script.
  • Le nombre d'URL disponibles est le même que le nombre de prims disponibles sur la parcelle sur laquelle l'objet se trouve.

    Le propriétaire de l'objet ne compte pas, tous les objets d'un terrain utiliseront la réserve de ressources de ce terrain.

    Comme pour les prims, toutes les parcelles appartenant au même propriétaire dans la même région partagent la même réserve de ressources.

    Si vous avez deux terrains dans une région qui peuvent chacun prendre en charge 100 URL, alors vous pouvez en utiliser 200 depuis le ou les objets d'une seule de ces parcelles.

  • Le bonus en objets d'une région ne s'applique pas aux URL disponibles.

    Si une parcelle a un maximum de 300 prims dans une région avec un facteur de bonus 2x il n'y aura que 150 URL autorisées.

• Chaque résident dispose de sa propre réserve unique d'URL disponibles avec un maximum de 38 URL par résident.
  • Cela correspond à 1 URL par point d'attachement, mais toutes les 38 pourraient être utilisées par un seul objet attaché, par exemple.
• Les véhicules sont traités à part et rattachés de manière lâche aux réserves des résidents selon la logique suivante :
  • Tout objet sur lequel un résident est assis est un "véhicule"
  • Les véhicules utiliseront les ressources en URL de la parcelle sur laquelle ils se trouvent jusqu'à ce qu'ils dépassent une limite de terrain.

    En particulier, cela empêche quelqu'un de détraquer votre vendeur automatisé en s'asseyant dessus en en faisant un "véhicule".

  • Quand un objet utilisant des ressources en URL avec un résident assis dessus traverse une limite de parcelle, les resources basculent vers le premier résident assis ayant assez de ressources. Si aucun agent assis n'a assez de ressources, alors les ressources de la parcelle dans laquelle on entre seront utilisées. S'il n'y a toujours pas assez de ressources à utiliser, alors le déplacement du véhicule est empêché.

    Pour résumer, nous faisons tout notre possible pour trouver une réserve où piocher les ressources nécessaires pour le véhicule, mais nous bloquons le mouvement si c'est impossible.

• Vente de terrain : quand un terrain est vendu, cela change le nombre total d'URL disponibles dans la région pour les deux résidents (le vendeur et l'acheteur). Si à cette occasion, plus d'URL sont utilisées qu'il n'y en a de disponibles, des objets seront renvoyés.
  • Les objets renvoyés le seront du plus récent au plus ancien parmi ceux qui utilisent des URL, pour chaque catégorie parmi les catégories suivantes : temporaire, apaprtenant à une autre personne, appartenant à un membre du groupe, appartenant au propriétaire, sélectionné ou assis dessus.

    Le seul cas où des objets sont ranvoyés c'est lorsque les terrains changent de propriétaire et uniquement lorsque plus de ressources qu'il n'y en a de disponibles sont utilisées.

    On renvoie les objets temporaires les plus récents avant les objets temporaires plus anciens avant les objets appartenant à une autre personne les plus récents avant... etc.

Autres limitations

• La taille du corps des requêtes sera limitée à 2 ko.
• La taille des entêtes de requêtes sera limitée à 255 octets.
• La taille des réponses aux requêtes n'est pour le moment pas limitée, mais cela pourra changer.
• Le type de contenu des données renvoyées est pour le moment toujours 'text/plain; utf-8'

  On pourrait autoriser d'autres types de contenu dans le futur, mais ce n'est pas garanti.

• On laisse tomber toutes les requêtes au delà de la 64ème en cours. C'est une conséquence du nombre maximal d'évènements en attente en LSL.
• On pourrait également réduire le rythme maximal auquel on accepte les requêtes sur le serveur de "capabilities". C'est possible, mais n'a pas encore été décidé.

Liens

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