Notes de version Easyling - novembre 2016

Novembre a commencé avec notre spécial Halloween (avez-vous remarqué l’icône du navigateur ?), et a apporté avec lui plusieurs nouvelles améliorations des capacités de traitement du Proxy. Le Translation Proxy peut désormais gérer du JavaScript transformé en chaîne dans d’autres JSON, nous avons reformulé le journal de crawl joint aux e-mails, le Remote Cache peut désormais être configuré pour stocker des images également, et les méthodes DELETE peuvent être utilisées via le proxy (avec quelques réserves). Consultez tous les détails après le saut !

 JavaScript dans JSONString

La capacité du Proxy à traduire des variables JavaScript et des réponses JSON aux requêtes n’a rien de nouveau. Nous avons même eu la capacité de traduire des JSON sérialisés. Cependant, le JavaScript sérialisé n’a été rendu possible que grâce au déploiement récent du Flexible Content Pipeline, qui nous permet d’étendre nos capacités de traitement presque sans limites.

Considérez la réponse suivante :

<code id="highlighter">{
    "plaintext":"chaîne de test, veuillez ignorer",
    "script":"var test = \"une autre chaîne de test, veuillez ignorer\"; alert(test);"
}</code>

et les JSONPaths suivants :

<code id="highlighter">json.plaintext
json.script javascript
json.script.test</code>

La première règle est assez évidente : elle marque la clé donnée comme traduisible. La deuxième et la troisième sont, en revanche, nouvelles. Tout comme l’ancien commutateur html, ceci modifie le mode de traitement du Traducteur, permettant à l’utilisateur de poursuivre le chemin sur la ligne suivante afin de sélectionner des variables déclarées dans le code JS envoyé (dans ce cas, la variable à afficher dans une fenêtre contextuelle).

Cache distant et images

Il n’est pas nouveau non plus que le Proxy puisse stocker les données brutes du site source et les réutiliser comme base de traduction. Cette fonctionnalité s’appelle le Source Cache. Lors de la création initiale du Source Cache, il était limité au HTML, CSS et JavaScript uniquement — les données d’image étaient entièrement ignorées en raison de contraintes de taille. Ce qui a conduit à des scénarios potentiellement malheureux, les images pouvant toujours être modifiées ou supprimées sur le serveur source.

Ce n’est plus le cas. Nous avons également mis en place une méthode permettant de mettre en cache les images référencées sur les pages que le robot d’exploration visite, et de les réutiliser lors de la diffusion. Bien entendu, cela reste soumis à la même limitation de taille que les autres ressources que nous pouvons stocker. De plus, l’option est toujours en phase BÊTA publique - si vous souhaitez qu’elle soit activée sur un projet, veuillez contacter notre canal d’assistance afin de faire activer l’option.

Méthode HTTP DELETE

La spécification HTTP définit un certain nombre de « méthodes » ou de « verbes » pouvant être utilisés pour indiquer la nature d’une requête donnée au serveur, et qui sont couramment utilisés dans les portails destinés aux clients. L’une de ces méthodes est DELETE, utilisée pour signaler une demande de suppression d’une ressource. Nous avons récemment également implémenté notre prise en charge de cette méthode, permettant ainsi le proxying de portails destinés aux clients (ou, du moins, d’une gamme plus large de sites web) tout en préservant les fonctionnalités.

Il convient toutefois de mentionner une mise en garde importante : en raison des limitations de l’infrastructure sous-jacente de Google AppEngine, la transmission du corps de la requête avec des requêtes DELETE n’est pas prise en charge ! Cela signifie que, bien que la requête soit transmise, son corps sera supprimé, ce qui peut entraîner un comportement erroné ou indéfini sur le serveur distant.