Get out ngrep and make sure that pywebdav is honoring the Connection:
close request proxied via nginx. I have found that nginx waits for the
socket to close before forwarding the request. This is correct
behaviour for a HTTP/1.0 proxy, but most servers are used to HTTP/1.1
clients who are less correct in their handling of HTTP/1.0.

Cheers

Dave

On 09/07/2009, at 7:14 AM, Cliff Wells wrote:

> I'm experimenting with WebDAV using pywebdav:
>
> http://code.google.com/p/pywebdav/
>
> It appears to work quite well if I connect to it
> directly (using either Nautilus and Cadaver as client).
>
> However, when I attempt to proxy to it via Nginx,
> I get messages that it's not a WebDAV-enabled share.
>
> Here's my nginx.conf:
>
> http {
> include mime.types;
> default_type application/octet-stream;
>
> server {
> listen 80;
> server_name _;
>
> location / {
> proxy_pass_header Server;
> proxy_set_header Host $http_host;
> proxy_set_header X-Forwarded-For $remote_addr;
> proxy_pass http://127.0.0.1:8008;
> }
> }
> }
>
>
> Cadaver reports the following (nautilus message isn't too
> informative):
>
> $ cadaver http://localhost/
> Could not access / (not WebDAV-enabled?):
> Unknown transfer-coding in response
> Connection to `localhost' closed.
> dav:!>
>
>
> I can see the request reaches pywebdav:
>
> localhost - - [08/Jul/2009 14:10:40] "OPTIONS / HTTP/1.0" 200 -
> localhost - - [08/Jul/2009 14:10:40] "PROPFIND / HTTP/1.0" 207 -
>
>
> Nginx access log shows:
>
> 127.0.0.1 - - [08/Jul/2009:14:11:20 -0700] "OPTIONS / HTTP/1.1" 200
> 0 "-" "cadaver/0.23.2 neon/0.28.2"
> 127.0.0.1 - - [08/Jul/2009:14:11:20 -0700] "PROPFIND / HTTP/1.1" 207
> 593 "-" "cadaver/0.23.2 neon/0.28.2"
>
>
> Nginx error log shows nothing.
>
>
> Regards,
> Cliff
>
> --
> http://www.google.com/search?q=vonage+sucks
>
>