Durante lo sviluppo di PicoStreamer mi sono imbattuto in una cosa davvero strana.

Ma cominciamo dall'inizio. Il Source Client di PicoStreamer invia l'audio al server utilizzando il normale protocollo HTTP. Nello specifico, usa una richiesta di tipo POST verso un normale script CGI.

Nel comporre una richiesta HTTP, lo standard vuole che siano indicati degli header obbligatori, come minimo l'Host, il Content-Type e il Content-Length. Bene, volendo essere rispettoso dello standard, ho regolarmente inserito gli header nella composizione della richiesta HTTP.

Come Host, ho messo naturalmente quello impostato nel client e come Content-Lenght (la lunghezza della parte body della richiesta) ho messo un valore abbastanza alto (quello esatto è impossibile saperlo, dato che è una trasmissione live...).

Due parole sul Content-Type: questo valore serve a specificare il tipo di dati che si stanno inviando. Per la cronaca, è quello che in fase di download fa capire al browser il tipo di documento che sta ricevendo (es. text/html per le normali pagine html o audio/wav per i file .wav).

Poichè PicoStreamer trasmette audio in mp3, ho pensato bene di metterci audio/mpeg che è appunto il Content-Type giusto per i file mp3. Tutto regolare: PicoStreamer funzionava correttamente con tutti i tipi di connessione e con tutti i provider. Tranne che con uno: Fastweb!!! Come mai? Grosso problema! Proprio chi ha l'enorme disponibilità di banda, always on, come quella che fornisce Fastweb sarebbe stato l'utente più interessato ad usare PicoStreamer, ma il Source Client non andava.

In effetti andava, si connetteva, ma trasmetteva soltanto pochi KB. Dopodichè tutto si fermava, mantenedo la connessione tcp attiva, ma nessun traffico riusciva a raggiungere il server. Allora ho pensato: Fastweb ci mette lo zampino!

Ho provato a sostituire il Content-Type con application/octet-stream, che significa più o meno: "non sono dati che ti interessano, sono solo una sequenza di byte". Risultato: funziona!!! Anche con Fastweb!!! Come mai?

Perchè Fastweb blocca l'upload se trova il Content-Type settato a mp3, e invece lascia passare tutto se ce n'è un altro? La cosa puzza di monitoraggio: ho come l'impressione che sui gateway perimetrali di Fatweb ci sia montato uno "sniffer" che lavora al livello applicazione.

Evidentemente questo "ipotetico" software ha una qualche disfunzione quando trova che si sta scambiando materiale audio mp3 (in effetti, in upload è un evento raro). Non credo che il blocco sia voluto, piuttosto penso che tale software sia messo lì solo a scopo di "logging".

Logging? Questo vuol dire che tutti gli utenti Fastweb sono monitorati nello scambio di dati con l'esterno della rete. Ma gli utenti Fastweb lo sanno? La legge è d'accordo su questo?

Magari starete pensando che queste sono solo mie fantasie ma... se avete un pò di pratica di programmazione e di HTTP fate una prova: magari scoprirete altri Content-Type che non vanno giù al preziosissimo software di monitoraggio di fastweb.