Francois PIETTE wrote: >> Using hgWillSendMySelf I noticed the proxy server immediately connects >> the client to the server and the connection is kept open as long as I'm >> sending data. If the proxy server does the same for the "long HTTP post" >> it would provide a very valuable tool for what I need. >> > > I wouldn't base my software on this behaviour which is defenitely not > guaranteed. HTTP protocol is a stateless protocol and you have poor > connection control. Just ask for the connection to be kept alive and hope it > is. If it isn't, then it will be reopened anyway by the component. > > > None of the things I'm doing expects the HTTP protocol to be anything but stateless. I'll re-explain how my downstream (that is - HTTP download) connection works. The client requests a document from my web server. It does this going through the proxy. The server response (200 OK), does NOT send an Content-length header and starts sending the document very very slowly, but it keeps sending for ever. It looks just like a large file download over a very slow link. Since there's no Content-length header the proxy is unable to determine if the document has finished downloading or not, it will keep receiving the given document for as long as the server sends. I noticed the proxy does one other nice thing: it immediately relays all received data to the client, and it really makes sense.
Real-life example that should force the proxy to behave in this very same manner: The client is downloading a 4Gb ISO image through the proxy. The proxy can't possibly wait for the WHOLE download to finish before starting to relay data to the client, it just doesn't make sense. It must start sending data to the client as soon as data is available. What I'm thinking about is using the very same thing the other way around: Doing a slow POST! I do understand downloading and uploading are governed by different rules, so I'd like to try this too. If you still say it's unlikely to work, I'll stop trying (by now I'm sure I explained things clearly enough so there's no misunderstanding). >> On a different note, how do programs like "zebedee" provide a TCP/IP >> tunnel through a HTTP proxy? I understand how the "downstream" part >> works, but how about the "upstream" part? >> > > This is quite easy. You can send the command "CONNECT" to a HTTP proxy and > then the proxy will work transparently as a simple relay, without ever > trying to understand what you send in the stream. This is how HTTPS works > thru the proxy. Since HTTPS encrypt everything, the proxy is unable to do > anything. It can just relay the data. That's the purpose of the "CONNECT" > command. > I might try implementing this as well. Trying an CONNECT first and, if that doesn't work, fall-back to alternative, slower methods. Can the THttpCli component be used for proxy CONNECT only, bypassing everything else? Or should I start with a vanilla TWSocket and work my way from that? 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
