On 26/11/2012 23:23 , James Graham wrote:
> On Mon, 26 Nov 2012, SULLIVAN, BRYAN L wrote:
>> To implement SSE using PHP for server scripting, I have found a number
>> of SSE dependencies that require configuration of PHP, Apache (or
>> other server), or the intersection of PHP and the underlying web
>> server. These include:
>> - turn output compression off (Apache)
>> - turn output buffering off (Apache?)
>> - set implicit flush (PHP)
>> - PHP 5.4 (I have not been able to get SSE working with PHP 5.3)
>>
>> I'm not sure of the interaction of these, but I have found very little
>> useful information about server configuration for SSE, and had to
>> spend a long time hacking on the server config to get it to work.
>
> It is possible that there's something magic in our setup, but I don't
> see anything obvious. I haven't dug through the PHP config or anything
> yet though. But this is all very hypothetical. If the tests work on the
> W3C server maybe we don't need to have this conversation at all. Is
> there some evidence that they don't?
Well, it's notoriously easy to get PHP to behave wildly differently just
by flicking one switch in its configuration. And Apache can be pretty
good at that too. If the tests work on the W3C server but it just
happens to be because we serendipitously have the right configuration it
would be good to document this because it's likely that we might change
some part of that configuration at some point, typically because another
test suite requires a change. So if this is non-obvious to set up, at
the very least it would be good to have it documented (and if possible
specifically turned on by the TS, e.g. using .htaccess).
FWIW the problems Bryan lists, if true, don't stem from not being a
"real web developer" as he says. They're actually the sort of issues
that real web developers have to deal with regularly. If we can
alleviate that for people who want to hack on the TS (and for your poor
friends who get to configure the server :) then so much the better.
>> And PHP is only one of the server options (and a poor man's one at
>> that, AFAICT). Shouldn't we be testing this with different server
>> environments?
>
> Not obviously. I mean as long as we have one server that correctly
> fulfills its side of the spec bargin that is sufficient for our
> purposes; the goal is to ensure that the clients implement the spec
> correctly, not determine the relative merits of PHP vs node.js vs
> twisted vs whatever for the server side.
Agreed, we're not trying to assess the correctness of a given
server-side implementation of SSE (though we could possibly have a TS
for that, too). So just one server implementation should be enough (so
long as it behaves predictably and in the way we want).
That said, there may be a case to be made that Apache+PHP is not the
best testing environment. The problem with both of these is that they
add a fair bit of magic and automatic behaviour, and that can get in the
way of testing and might lead to false positives/negatives. For
instance, we can't seem to figure out how to get Apache to let one of
our PHP scripts to handle OPTIONS requests and that's rather annoying.
It's also difficult to get Apache to return a broken HTTP response,
which can also be useful in testing. A bare-bones, roll everything up
yourself test server could help here.
--
Robin Berjon - http://berjon.com/ - @robinberjon