Un semplice tunnel http

[ilsensine]

Devo far transitare il protocollo di due applicazioni tramite protocollo http, in modo da poter passare attraverso proxy. La mia idea è far aprire al client un canale con GET, dove il server imposta nella risposta un Content-Type: application/octet-stream e Transfer-Encoding: chunked, quindi procede ad inviare i dati nel formato previsto da questo transfer; il client apre un canale con POST e invia i dati nella stessa maniera.
Essendo alquanto ignorante della materia, chiedo:
- si può usare Transfer-Encoding: chunked con POST?
- sarebbe bello poter utilizzare la stessa connessione per inviare i dati sia in un verso che nell'altro. E' possibile? (da alcune prove che ho fatto, sembrerebbe di no)

[cionci]

Fammi capire devi ottenere un canale di comunicazione bidirezionale e, soprattutto, sempre aperto tramite HTTP ?

[ilsensine]

Fammi capire devi ottenere un canale di comunicazione bidirezionale e, soprattutto, sempre aperto tramite HTTP ?
Sarebbe l'ottimo, ma posso fare i conti con quello che ho a disposizione. Il mio problema è che non ho sufficiente esperienza in questo campo per sapere cosa è supportato e cosa no.
Ho appena visto, ad esempio, che non posso fare una trasmissione "chunked" con POST o PUT. O, almeno, squid non la supporta. Riguardo il canale bidirezionale, mi sono messo l'anima in pace.

Se ne sai qualcosa sulle tecniche a disposizione, ogni consiglio è bene accetto.

[kingv]

ma devi farlo tu applicativamente?
usare un supporto esterno (tipo http://www.nocrew.org/software/httptunnel.html ) non è un'opzione?

[ilsensine]

ma devi farlo tu applicativamente?
usare un supporto esterno (tipo http://www.nocrew.org/software/httptunnel.html ) non è un'opzione?
L'ho visto, non sembra idoneo al mio caso. Volevo implementare qualcosa di semplice a livello applicativo.

[cionci]

Vediamo, me ne vengono in mente due:

- Sfrutti Java RMI ed il supporto tunnel HTTP (è realizzato tramite CGI) in modo da pacchettizzare i dati in chunk da inviare tramite oggetti RMI.
- Se entrambi gli endpoint sono dietro ad un proxy HTTP: ti crei una servlet che permetta riceve i dati a pacchetti (tramite POST) e specularmente invia i dati da trasmettere all'altra servlet. Ovviamente di fatto sono due connessioni HTTP separate.

[ilsensine]

Vediamo, me ne vengono in mente due:

- Sfrutti Java RMI ed il supporto tunnel HTTP (è realizzato tramite CGI) in modo da pacchettizzare i dati in chunk da inviare tramite oggetti RMI.
-ENOJAVA
- Se entrambi gli endpoint sono dietro ad un proxy HTTP
No il lato server è pubblico

Più che utilizzare cose esistenti, volevo qualche dritta sul protocollo in se per implementare una soluzione semplice tagliata per il mio caso specifico. Il protocollo http in se non è complesso.

[cionci]

Sul lato pratico...l'architettura esistente qual è ?

Server | Proxy <<<-->>> Client
Client | Proxy <<<-->>> Server

Suppongo la seconda, giusto ?
Il proxy è trasparente o non trasparente ?

[ilsensine]

Da quello che ho visto fin'ora, la trasmissione s->c è facilmente realizzabile tramite un GET e una risposta chunked. Questo mi offre la massima flessibilità sui dati trasmessi. La parte c->s è un pò più complicata, visto che non posso usare il trucco della trasmissione "chunked" devo usare un classico POST esplicitando il content length ed attendendo l'http ok di risposta. L'identificazione dei due canali come un unico strato di trasporto posso farla impostando un "fake cookie" nel GET, e rimandandolo indietro nel POST. Il cookie passa tranquillamente il proxy. Dovrebbe andare, credo...

[ilsensine]

Sul lato pratico...l'architettura esistente qual è ?

Server | Proxy <<<-->>> Client
Client | Proxy <<<-->>> Server

Suppongo la seconda, giusto ?
Sì la seconda. Dovrebbe funzionare sia in modalità proxy trasparente che esplicito (posso configurare il client per uno dei due casi).

[cionci]

Fai per favore qualche prova di questo tipo, a seconda del proxy dovrebbe funzionare.

Inizia la connessione in HTTP 1.1 in questo modo il proxy dovrebbe capire che deve lasciare aperta una connessione fino a quando uno degli endpoint non la chiude. Così puoi scambiarti dati continuamente con una sequenza POST dal client/risposta del server.
Dal Client invia una richiesta POST avente come destinazione il tuo server e nel body mettici i dati RAW (fregatene dell'encoding visto che è una cosa che dovrebbe riguardare solo il server di destinazione e il proxy possibilmente non dovrebbe metterci le mani). L'unica cosa consistente dovrebbe essere la dimensione dei dati da specificare nell'header.
Dal server rispondi con un header HTTP/1.1 200 (importante anche qui la dimensione dei dati) e gli ci butti dietro i dati di risposta in RAW.
Ovviamente il client non potrà inviare un POST di dimensione incgnita quindi stabilisci la dimensione massima da bufferizzare e quando il buffer è pieno trasmetti. Il server dovrà sempre rispondere ad una richiesta POST anche se non ha dati da trasmettere.
La connessione *dovrebbe* rimanere aperta quindi di fatto hai una connessione bidirezionale anche se devi pacchettizzare i dati.

[cionci]

Da quello che ho visto fin'ora, la trasmissione s->c è facilmente realizzabile tramite un GET e una risposta chunked. Questo mi offre la massima flessibilità sui dati trasmessi. La parte c->s è un pò più complicata, visto che non posso usare il trucco della trasmissione "chunked" devo usare un classico POST esplicitando il content length ed attendendo l'http ok di risposta. L'identificazione dei due canali come un unico strato di trasporto posso farla impostando un "fake cookie" nel GET, e rimandandolo indietro nel POST. Il cookie passa tranquillamente il proxy. Dovrebbe andare, credo...
Io non andrei ad implementare il protocollo HTTP, ma "falsificherei" il protocollo in modo che venga riconosciuto dal proxy.

[ilsensine]

Sto facendo proprio prove di questo tipo, dovrebbe funzionare. L'unica incognita è se il proxy decide di buttare giu spontaneamente una connessione keep alive. Sul secondo canale potrei anche tollerarlo tutto sommato, il canale iniziato con GET invece non dovrebbe cadere.

Sto facendo le prove con squid, che implementa solo l'http 1.0 (ma l'encoding chunked lo fa passare, questo è importante).