Francois Piette wrote:
> This is proxy implementation dependent. The proxy could buffer the document
> up to some point and then give up and forward everything. It could also
> handle document differently according to the content-type.
> If you consider this would not happend, then it's OK for me. I'm just giving
> you the ideas I have :-)

Thanks for the input, it's good to know how things might fail :)

For my "downstream" connection I'll use the following logic (when proxy 
is enabled):
(a) Try CONNECT; If it fails go to (b)
(b) Start my standard HTTP Wizardry; At the first NOP received send an 
"ACK" to the server, letting it know I actually got the message. If the 
server has a "real" message to send (ie: not a NOP) and it hasn't 
received any NOP-confirmation yet, I'll send the message and then close 
the connection. If the server has already received an ACK for a NOP when 
it needs to send the real message (and the ACK was received in a timely 
manner) I'll know the proxy is relaying all sent data in a timely manner 
and I'll send the "real" message without closing the connection.

In my opinion this should work, no matter how the server is configured. 
It should also work if I'm dealing with an transparent proxy (so I don't 
actually know I'm dealing with a proxy). Do you see any wholes in my logic?

Unfortunately for my "upstream" connection I only have two options: use 
CONNECT or use successive POST's; The "successive POSTs" variant doesn't 
sound all that good, since I also want to "tunnel" interactive traffic 
through the HTTP proxy (interactive=VNC, not plain-old chat; Chat would 
pose no problem)

Cosmin Prund
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to