On Jun 8, 8:59 pm, Simon Sapin <[email protected]> wrote: > Now, if the length is correct in serving.py, this is most likely a > network problem. Is this on localhost? Do you have a firewall or > something that could interfere? > > If the length is not correct in serving.py, the problem is somewhere > between that and where the response is generated (where you have > Content-Length set to len(body).) Looking at your traceback, this means > in OpenERP. I’m not familiar with OpenERP so I can’t help much more > thane that …
Thanks for the advice! It seems that "sum(map(len, application_iter))" changed the iterator, so the application broke when I tried this. But I simply output the length of the data in the loop, and that was the same, as the output was a sequence of just one string. I logged the size of the data to be written in method write() (here: https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/serving.py#L132) And right before "self.wfile.write(data)" the size was still the correct one. I looked up that "self.wfile" might be a file object returned by Python's standard library's "socket.makefile()" (where "socket" is something returned by another "socket's" "accept()"), so it should be working correctly, right? So, it's a network problem… My situation is this: the Python script (OpenERP) is running on a Linux machine presenting the web interface on a (localhost) port. I'm pointing the browser to a localhost port which is then forwarded to the (remote) Linux machine port via an SSH tunnel by Putty. Between the browser and the Putty I also have Fiddler (HTTP Debugging Proxy) to better catch the errors, but the problems are there also when I do not use Fiddler. Janis -- You received this message because you are subscribed to the Google Groups "pocoo-libs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pocoo-libs?hl=en.
