On Wed, May 24, 2006 at 05:44:56PM -0400, Adam Zey wrote: > Curt Zirzow wrote: > >On Tue, May 23, 2006 at 06:37:27PM -0400, Adam Zey wrote: > > > >>The data going from client->server needs to be sent over an HTTP > >>connection, which seems to limit me to PUT and POST requests, since > >>they're the only ones that allow significant quantities of data to be > >>sent by the client. Ideally, there should be no delay between the client > >>wanting to send data and the data being sent over the connection; it > >>should be as simple as wrapping the data and sending. > > > > > >>So, I need some way to send data to a PHP script that lives on a > >>webserver without any buffering going on. My backup approach, as I > >>described in another mail, involves client-side buffering and multiple > >>POST requests. But that induces quite a bit of latency, which is quite > >>undesirable. > > > > > >How much data are you sending? A POST shouldn't cause that much > >delay unless your talking about a lot of POST data > > > >Curt. > Please see my more recent messages on the subject for the reasoning > behind this. It's interactive data being sent that may require an I didn't ask why... I was asking how much. > immediate response. If a user is tunneling a telnet session, they expect > a response within a matter of milliseconds, not seconds. POST holds onto > the data until the client is done uploading, which with a persistant > POST request never happens, which is why I spoke of multiple POST > requests above and in more recent messages. The only way you will be able to read data as it comes in is by removing php's reading and parsing of data from the HTTP posted data. I posted how to do this on a different thread. Curt. -- cat .signature: No such file or directory -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
