Re: Opera's SSE Tests on GitHub [Was: <different topic>]

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

Received on Tuesday, 27 November 2012 09:21:22 UTC