I've contacted the developer about a proper work-around and am currently waiting for a response.

Aaron Bull Schaefer (elasticdog@aur.archlinux.org) wrote:
> Hi Simon, I'm a packager for Arch Linux, and I have recently come
> across an issue with woof and Python 2.7. Here's the gist of it:
>
> $ woof example.txt
> Now serving on http://192.168.1.104:8080/
> aaronslaptop - - [21/Nov/2010 19:05:16] "GET /example.txt HTTP/1.1" 200 -
> ----------------------------------------
> Exception happened during processing of request from ('192.168.1.243', 58388)
> Traceback (most recent call last):
> File "/usr/lib/python2.7/SocketServer.py", line 284, in
> _handle_request_noblock
> self.process_request(request, client_address)
> File "/usr/lib/python2.7/SocketServer.py", line 310, in process_request
> self.finish_request(request, client_address)
> File "/usr/lib/python2.7/SocketServer.py", line 323, in finish_request
> self.RequestHandlerClass(request, client_address, self)
> File "/usr/lib/python2.7/SocketServer.py", line 641, in __init__
> self.finish()
> File "/usr/lib/python2.7/SocketServer.py", line 694, in finish
> self.wfile.flush()
> File "/usr/lib/python2.7/socket.py", line 301, in flush
> self._sock.sendall(view[write_offset:write_offset+buffer_size])
> error: [Errno 32] Broken pipe
> ----------------------------------------
>
> ...I don't do much Python development, and so thought I'd check with
> you to see if you had any suggestions. This has been reproduced by a
> number of users and on numerous machines. Googling for broken pipe
> errors wasn't too enlightening either. Any help you can give on
> working around this issue would be much appreciated!


Uh, I don't really know what is going on there. A "broken pipe" in this
context probably means, that the network connection broke down for some
reason. It would be helpful to see a wireshark dump of this, maybe it
then is possible to discern, what the actual reason for this bug is. It
at least is not some blatantly obvious programming error... :)

I did not see this too frequently here, so I'd be glad if you could
create a wireshark dump and maybe provide it to me. Note that there
might other sensitive data in the wireshark dump, so make sure you check
it before just sending it to me.

Hope this helps,
Simon
--
simon@budig.de http://simon.budig.de/

To me it happens every time I try. I've attached a capture file from wireshark.

wget --tries=1 10.0.0.118:8080
--2011-01-08 19:29:11-- http://10.0.0.118:8080/
Connecting to 10.0.0.118:8080... connected.
HTTP request sent, awaiting response... 302 Found
Location: /TESTFILE [following]
--2011-01-08 19:29:11-- http://10.0.0.118:8080/TESTFILE
Connecting to 10.0.0.118:8080... connected.
HTTP request sent, awaiting response... No data received.
Giving up.

orphan. assigned to last packager

At least I know where it's failing. When you download a file from woof,
woof forks a child process to handle the actual download. And for whatever
reason, we're getting SIGPIPE in that child process. Could the parent
possibly be doing something to close the connection? I don't know,
but I'll try to contact upstream.

Sorry about this. It's basically my fault, because I rebuilt this during
the Great Python Transition of 2010.

-- Chris

Upstream is aware of the issue. Unfortunately, it doesn't look like there's
an easy fix for Python 2.7.
I'm going to close the bug soon.
Since this package will likely be broken for the foreseeable future, I'm
probably going to send it back to [unsupported].

I have created a patch, that makes woof work with python 3 and submitted it to AUR as woof-python3 http://aur.archlinux.org/packages.php?ID=46323
Most work is done by the 2to3 tool. This at least solved the problem for me.