Hi folks, Working with M. David Peterson trying to run the CherryPy HTTP server on IP under Windows we ran into a fairly subtle bug that was actually not so subtle at all.
When the server accepts a connection it maps the socket into a file object so that it can read and write with a nice API. When using IPCE socket module this achieves the same by doing this: def makefile(self, mode='r', bufsize=-1): stream = NetworkStream(self.socket) return file(stream, mode) This works great when you don't care about the way the end of the lines is defined but if you do be ready for some hair-tearing hours. Indeed with IronPython running on Windows with the .NET framework the end of the line is defined as <LF> whereas for instance on Linux with Mono it's <CR><LF>. If I'm not mistaken CPython always ensures the end of line is <CR><LF> so that people don't have to worry about the underlying OS behavior. The problem I faced is that HTTP marks the end of the header lists via a <CR><LF> but because CherryPy reads the socket as a file it only gets a <LF> with IP under Windows and therefore fails miserably. I've added a test for a single <LF> in my copy of CherryPy and it fixed the problem. But this is a bit of a hassle. I don't think there is a bug of any of the part here. However I believe there should be either a very clear warning that this difference will always exists and Python developer will have to check for that case, or maybe IP should find a way to ensure that <CR><LF> is always returned even under Windows (which I doubt is an easy thing to do). In any case if your code depends on the line ending be aware of that difference as you could end up swearing too loud for your own good. - Sylvain _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com