XML, XML-RPC e Python nel 2009

Durante la fase di qualificazione di un progetto software che stiamo portando avanti da quasi 3 anni, è stato riscontrato un bug che mi ha fatto perdere più di una giornata per trovarne la soluzione. Il tempo perso non è dovuto tanto alla complessità del problema (la soluzione, ovviamente, era più che banale), ma piuttosto al fatto che, inconsciamente, non accettavo il fatto che quello potesse essere il problema.

Il software è un sistema di gestione centralizzato di un parco macchina. Tramite un demone implementato su Twisted, fornisce un servizio per l’accesso alla configurazione e uno per il controllo verso le macchine. Quest’ultimo è basato su una interfaccia piuttosto semplice in XML-RPC. Le macchine controllate accedono ai dati e riportano i risultati.

Una delle funzionalità implementate riguarda la possibilità di eseguire campagne di esecuzione di script (di qualunque natura, purchè la macchina abbia gia’ a disposizione l’interprete con cui viene scritto). Le macchine ricevono lo script, lo eseguono, restituiscono indietro alcuni dati, tra cui l’exit code e l’output (stdout + stderr in formato annotated).

Sembra facile, no?

La codifica utilizzata è sempre e ovunque UTF-8, per cui l’output dello script viene (anzi, veniva) dichiarato nel payload XML-RPC come un semplice <string>. Tanto, UTF-8, qualunque cosa va bene, no?

I primi test vanno a buon fine. Poi il problema: alcuni script fanno sollevare una eccezione di “malformed token” da parte del servizio che riceve i dati. Possibile?

Server e client implementati in python. Il client utilizza xmlrpc, che si trova nella libreria standard.

Ora, possibile che nel 2009 , utilizzando un linguaggio ad alto livello, utilizzando un modulo della libreria standard, debba essere io a preoccuparmi che i caratteri che non possono stare in XML vengano codificati correttamente, come, ad esempio, i caratteri ASCII da 0 a 31? Perchè alcuni di questi vengono codificati automagicamente ( come ‘&’, o ‘<’), mentre altri no? Ma poi neanche tutti gli ASCII da 0 a 31, anche tra questi, alcuni sono gestiti dalla libreria, come il 9, il 10 e il 13…

Soluzione al problema: il dato passato non deve essere str ma xmlrpclib.Binary. Che si preoccupa di codifica/decofidica in base64 del payload. Semplice e veloce. Ma perchè ci devo pensare io? :)

Pages:
  1. puppa

  2. sincrono o asincrono?

  3. uffa… vai avanti a fare il fighetto con le tue cose strane senza senso….21 invio risolve qualunque problema!!!!!!! è così semplice, state sempre a farvi delle supercazzole ma in realtà è più facile di quanto pensiate!!!!!

Leave a Comment