Odeslani JSONu pres HTTP pomoci busyboxu

Casto po vyreseni nejakeho mensiho problemu davam jeho reseni na GitHub GIST.
Na klasicky clanek to byva kratke, ale i tak je skoda se nepodelit. Proto budu postupne, jak cas dovoli prochazet stare gisty, trochu vic je komentovat a tvorit z nich kratke clanky.
Dnes zacnu posilanim HTTP POST pozadavku pomoci busybox telnetu.

K cemu je to dobre? Casto je potreba z pc odeslat data ke zpracovani na server. Pokud jde o bezny „stolni pc“, muzeme vyuzit nejaky pohodlny Python/Java framework, obetovat par desitek MB RAM a vse bude krasne fungovat 🙂
Ja ale potreboval posilat data z OpenWrt routeru, ktery mel 4MB flash a 16MB RAM. Proto jsem hledal reseni s nejmensimi naroky na zdroje.
 
Vetsinou se stejne pouzivaji HTTP pozadavky. Protoze jde o plain-text protokol, je mozne jednoduse pouzit telnet klienta. Bezni telnet klienti v Debianu/Ubuntu maji trochu jinou syntax, nez busybox klient.
Pro vetsi univerzalnost pouziti jsem pouzil prave busybox telnet.
 
Zde je ukazka na poslani JSONu pres HTTP GET. Na zacatku se vola program, jehoz vystupem je validni JSON.
 
Protoze program neumi zpracovat HTTP odpoved ani pokracovat v posilani pozadavku, posila se hlavicka „Connection: close„.
Data se poislaji vzdy aktualni, proto hlavicky na zakazani cache.
Po posledni hlavicce musi podle RFC popisujici HTTP nasledovat prazdny radek a pote samotna data.
Dost pravdepodobne bude mit server problem kvuli chybejici hlavicce Content-Length.
Ukazka nefunguje s busybox telnetem, pouze s plnohodnotnym telnetem v Debianu/Ubuntu.
 
Vyse uvedeny kod ma nekolik problemu:
  1. Pohodlnejsi je posilani vytupu do telnetu pres rouru.
  2. Chybejici hlavicka Content-Length.
  3. Pokud je vystup prikazu hodne velky, nevejde se do promenne a cast se zahodi.
  4. Nepouziva kompresi, zbytecne plytvani pri prenosu.
  5. Nejde pres nej posilat binarni data.
 

Ad 1 & 2

 
Bez spatne, nebo zadne hlavicky Content-Length bude mit hodne serveru pravdepodobne problem se zpracovanim! Pri mem testovani tomu tak bylo.
 
 

Ad 3

resenim je pouzit docasny soubor. Jeho nazev bychom si meli nechat pridelit od systemu, aby nedoslo ke kolizi:
 
Na zaver po sobe uklidime temp soubor.
 
 

Ad 4 & 5

body 4 a 5 spolu dost souvisi. Na komperesi pouzijeme standardni gzip, protoze je snad vzdy v busyboxu. Serveru proste http hlavickou oznamime jenom podporu gzipu.
Protoze gzip data jsou binarni, bude problem s odeslanim. Temer ve 100% pripadu telnet klient v binarnich datech rozpozna nejake ridici prikazy a spadne.
Resenim je zagzipovat data a pak je prevest do base64. I tak je uspora oproti plain-textu znacna. Pro srovnani pri mem testu: cisty text zabiral 10580 bajtu a base64-gzip 3056 bajtu – 3,46x mene.
 
Nyni prichazi dalsi problem 🙂
V beznych distribucich mame utilitu „base64“. Busybox ji take obsahuje, ale dost casto je kompilovan bez ni. Takze si musime base64 generovat samy, idealne v shellu – opet cisty POSIX sh shell. 
Teoreticky to jde, ale nejde vubec o snadny ukol. Nastesti jsem nasel uz hotovou implementaci, jako bonus je pod public domain licenci.
Ze skriptu nas zajima pouze funkce encode(). Pro ukazku cast te magie:
 

Kompletni funkcni kod:

Vezme data, zkomprimuje gzipem a prevede do base64. Na zacatku souboru je mozne pomoci promenne GZIP urcit, zda se posle plain-text, nebo gzip+base64.
 
 
 
 

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *