Hi, Maciej, Thank you for your comment.
On Tue, Sep 8, 2009 at 2:18 PM, Maciej Stachowiak<[email protected]> wrote:
On Sep 7, 2009, at 10:00 PM, Mark Rowe wrote:
Python starting with v2.6 has reasonable built-in support for SSL servers. This is the version that ships with Mac OS X 10.6. Mac OS X 10.5 ships with Python 2.5 (predating this built-in support) but includes pyOpenSSL. Mac OS X 10.4 ships with Python 2.3 and does not include pyOpenSSL. From what I can see, Cygwin currently has Python 2.5 and does not appear to support pyOpenSSL.
It seems that only a small portion of the WebSockets tests would need to deal with SSL, while the majority of the tests would work fine on any platform supporting Python 2.3. For the SSL tests it would be reasonable to have tests that worked out of the box on only some platforms, especially when those platforms are used by the majority of WebKit developers (Mac OS X >= 10.5 and Linux). Doing this seems like a simpler approach than requiring two third-party Apache modules be built + configured on all platforms in order to run even the basic tests.
Building and installing some Apache modules doesn't seem like that big a deal to me, if it would really make testing more practical.
However, it seems like using a premade websocket server implementation would make some forms of testing harder. In particular, it would be more difficult to test what happens in the face of malformed results from the server, which is a very important part of testing.
So based on that, it probably makes more sense to do at least some of the testing and a lower level, so we can easily test invalid server responses.
Using mod_pywebsocket, we can write a server-side Web Socket handler for a URL and put it in a corresponding directory under LayoutTests/... A handler is a Python script and can send (or not send) arbitrary bytes, malformed or not, to the browser. A handler is called after Web Socket handshake. There is no way to send malformed messages during handshake, as far as mod_pywebsocket is functioning properly. We may need a different mechanism here. How do you test a case where the Web server returns broken HTTP headers, for example? Perhaps we can do similar for Web Sockets? Yuzo
Regards, Maciej
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
