Comments on: PHP and HTTP making friends

By: codestorm

codestorm — Thu, 10 Nov 2005 05:25:21 +0000

Also slightly off topic; please proofread your posts. Please.

By: solutionsphp

solutionsphp — Tue, 08 Nov 2005 18:49:01 +0000

Sorry, this is slightly off topic… I noticed that my subscription to this feed stopped sending me new articles about a month ago. I’m using Thunderbird to manage RSS. I have tried setting up this feeds again, but Thunderbird just takes forever trying to validate the feed, never does, and I am unable to subscribe. I have validated the feed and it passes. I CAN subscribe to other SitePoint feeds, just not this one right now. Is anyone else is having trouble subscribing to this feed?

cheers
SAM :)

By: Maarten Manders

Maarten Manders — Tue, 08 Nov 2005 18:01:24 +0000

Here’s what i found out about the KeepAlive-Issue (tested with Apache2, PHP4 and PHP 5):

Apache’s default KeepAlive header looks like this:
Keep-Alive: timeout=15, max=100\r\n
Which means: The connection stays open for 15 seconds after the last HTTP response. Additionally, there is a maximum of 100 subsequent requests allowed to prevent a user from keeping the connection open forever and thus hogging your server resources (RAM, that is, which is bad).

1. Regardless of what Apache’s value of KeepAlive is, $_SERVER[’HTTP_KEEP_ALIVE’] always seems to be equal ‘300′. This might be a bug.

2. I haven’t been able to change the KeepAlive header with header(’Keep-Alive: timeout=123, max=123′).

3. apache_setenv(’KeepAliveTimeout’, 123) seems to be useless as well.

4. One may change the KeepAlive in the apache config with:
KeepAlive 123
This accordingly changes the KeepAlive header sent to the client. However, changing the maximum requests count with
KeepAliveTimeout 321
doesn’t seem to change the header in any way. It stays at it’s default value (’100′). Then again I’ve seen Apache servers with a different max requests value so there must be a way to change it.

I’ll try to investigate this further as soon as i find more time.

By: HarryF

HarryF — Tue, 08 Nov 2005 09:51:50 +0000

Are there any known security issues or concerns so far?

For pecl_http? I guess one potential issue will be making sure that pages server “inside” an authenticated session don’t end up being cached by intermediate proxy servers - the problem is well described in the presentation I linked to above. Needs investigation.

Thinking of PHP and HTTP: I’ve been wondering if there’s a way to change HTTP_KEEP_ALIVE for a current connection from within PHP. Being able to lower it would help a great deal in increasing performance under heavy load.

I guess you could modify it with apache_setenv but whether that effect an active HTTP connection I don’t know. There’s probably some nightmares with IE + SSL as well.

Did you see the part in pecl_http about bandwidth throttling BTW? Not directly related but gives an indication of the sort of things that work with pecl_http.

Or is there an Apache module to dynamically change the keepalive time depending on the httpd load?

Not that I’m aware of. Think, in general, keep alives with dynamic pages is largely unknown territory.

By: Maarten Manders

Maarten Manders — Mon, 07 Nov 2005 14:35:27 +0000

Thinking of PHP and HTTP: I’ve been wondering if there’s a way to change HTTP_KEEP_ALIVE for a current connection from within PHP. Being able to lower it would help a great deal in increasing performance under heavy load.

Or is there an Apache module to dynamically change the keepalive time depending on the httpd load?

By: patrikG

patrikG — Mon, 07 Nov 2005 11:22:24 +0000

pecl_http: great potential, never heard of it. Thanks for the info.
I’m always a wee bit careful with AJAX, live_http, etc. due to the amount of hits they generate. The caching feature on pecl_http sounds fantastic (almost too good to be true).

Are there any known security issues or concerns so far?