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) Thanks, Cosmin Prund -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
