On Tue, May 23, 2006 5:23 pm, Adam Zey wrote:
>> why is port 80 a requirement - HTTP can technically over any port.
>>
> It must be accessible to any client, no matter what sort of firewall
> or
> proxy they go through. The only way to absolutely assure that is, as
> far
> as I know, to use port 80. It is the only port that you can count on
> with a fair degree of certainty, if the user is proxied or firewalled.
>
> I'd just as soon write my own simple webserver, but then it'd run into
> conflicts with existing webservers on port 80.
>
> My current solution is to buffer data on the client-side, and send a
> fresh POST request every so many milliseconds (Say, 250) over a
> keepalive connection with the latest buffered data. The downside of
> this
> is that it introduces up to 250ms of latency on top of the existing
> network latency, and it produces a lot of POST requests. I would
> really
> like to eliminate that by streaming the data rather than splitting it
> up
> like that.
You might maybe want to try running PHP as a CGI instead of Module,
just to see if the dirt-simple fopen('php://stdin','r') will "just
work"...
It's also remotely possible that you could check if there's a way to
implement "custom" methods other than GET/POST in PHP, which might
open up the possibility of getting partial data.
It's even remotely possible that PUT is not buffered, though I doubt it.
Ultimately, though, I think you've been painted into a corner from
which there is no real escape...
Might be time to re-negotiated.
You MIGHT be able to run a Proxy on the server side, so that your HTTP
port 80 for this particular URL gets forwarded to some other port/IP
behind the scenes -- and then PHP sockets may be viable.
This would meet most of the original requirements, and I think it
would work...
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
