/ Zope / Apsis / Pound Mailing List / Archive / 2006 / 2006-09 / pound, webdav, litmus - 4xx response body truncated?

[ << ] [ >> ]

[ Reverse proxy for linux server? / James ... ] [ RewriteRedirect http->https issue / Rob Moore ... ]

pound, webdav, litmus - 4xx response body truncated?
Roy McMorran <mcmorran(at)mdibl.org>
2006-09-21 20:31:25 [ FULL ]
Hello Pound experts,

I'm attempting to configure pound in front of an Apache-based webdav 
server (on the same physical host).  I'm planning to use pound to 
provide SSL-based access from outside the local network (although at 
present I'm testing inside, both with and without SSL).

The Apache webdav server has several vhosts that listen on 127.0.0.1:80 
only, and pound is configured to listen on the IP address of the 
server.  I'm testing webdav with litmus 0.10.5.  When I connect 
"unproxied" to the first Apache vhost at 127.0.0.1, litmus behaves as 
expected.

When I connect via the pound reverse proxy I see the following 
behavior:  Some responses from Apache are having the response body 
truncated.  Eg.  if litmus tries to establish a connection but gets a 
401 back.  Ordinarily it would try again with login credentials.  
However pound appears to remove the response body from the initial 401, 
which litmus does not like at all (nor does my Mac WebDAV client) and 
the client fails. 
 From litmus:
----
[status-line] < HTTP/1.1 401 Authorization Required^M
[hdr] Date: Wed, 20 Sep 2006 21:26:28 GMT^M
Header Name: [date], Value: [Wed, 20 Sep 2006 21:26:28 GMT]
[hdr] Server: Apache/2.0.55 (Unix) DAV/2^M
Header Name: [server], Value: [Apache/2.0.55 (Unix) DAV/2]
[hdr] WWW-Authenticate: Basic realm="Test"^M
Header Name: [www-authenticate], Value: [Basic realm="Test"]
[hdr] Content-Length: 401^M
Header Name: [content-length], Value: [401]
[hdr] Connection: close^M
Header Name: [connection], Value: [close]
[hdr] Content-Type: text/html; charset=iso-8859-1^M
Header Name: [content-type], Value: [text/html; charset=iso-8859-1]
[hdr] ^M
End of headers.
Reading 401 bytes of response body.
Aborted request (-3): Could not read response body
Closing connection.
Connection closed.
Request ends, status 401 class 4xx, error line:
Could not read response body: connection was closed by server.
----

This appears to happen with other responses as well, for instance a 423 
on a locked file.  I've also confirmed the response body is truncated by 
using Ethereal, er, Wireshark on both sides of the proxy (although the 
Content-Length header is unchanged).


I *know* people are using pound with webdav, so I expect that I'm just 
missing something here.  Have a look at my pound.cfg file:
----
User "apache"
Group "apache"
Daemon 0
LogLevel 2
LogFacility local2

ListenHTTP
# ListenHTTPS
  Address 123.123.123.123
  Port 80
  # Port 443
  # Cert "/etc/ssl/certs/mycert.pem"
  # CAlist "/etc/ssl/certs/myca.cer"
  xHTTP 2
  RewriteLocation 2
  RewriteDestination 1
  Service
    BackEnd
      Address vhost.host.my.org
      # the above resolves to 127.0.0.1
      Port 80
    End
  End
End
----


Server is RHEL 4, Linux 2.6.9 kernel, x86_64
Apache 2.0.55 w/mod_dav
Litmus 0.10.5
MacOS 10.4.7 client
Pound 2.0.9, 2.1.2, 2.1.3 all show the same behavior.

Any suggestions would be most welcome!

Thanks,[...]

Re: [Pound Mailing List] pound, webdav, litmus - 4xx response body truncated?
Robert Segall <roseg(at)apsis.ch>
2006-09-23 11:36:43 [ FULL ]
On Thu, 2006-09-21 at 14:31 -0400, Roy McMorran wrote:[...]

I find this puzzling. As far as I know Pound considers the following
situations to result in a no-content response:

- if the request was a HEAD, DELETE, LOCK or UNLOCK
- response codes 10x, 11x, 204, 304, 305 and 306

As you can see 401 is not one of them, and Pound will happily return the
contents associated with it. I suggest you try it with a regular browser
to convince yourself.

Could it be there is a problem with the litmus client? Time-outs, slow
responses, etc?[...]

Re: [Pound Mailing List] pound, webdav, litmus - 4xx response body truncated?
Roy McMorran <mcmorran(at)mdibl.org>
2006-09-25 15:38:40 [ FULL ]
Robert Segall wrote:[...]
Hi Robert, thank you for the reply.

Indeed when my browser sends a GET the 401 that returns does include the 
response body. 

In fact, the case which is resulting in the error I'm seeing is a DELETE 
verb, so it should fit your first condition noted above.  Perhaps the 
problem is the Content-Length header?  The response pound is sending to 
the WebDAV client still includes a Content-Length header that indicates 
the response body is present and (in this example) 401 bytes long:

[hdr] Content-Length: 401
Header Name: [content-length], Value: [401]
[hdr] Connection: close
Header Name: [connection], Value: [close]
[hdr] Content-Type: text/html; charset=iso-8859-1
Header Name: [content-type], Value: [text/html; charset=iso-8859-1]
[hdr]
End of headers.
Reading 401 bytes of response body.
Aborted request (-3): Could not read response body
Closing connection.
Connection closed.
Request ends, status 401 class 4xx, error line:
Could not read response body: connection was closed by server.


Thanks and best wishes,
-r
[...]

Re: [Pound Mailing List] pound, webdav, litmus - 4xx response body truncated?
Robert Segall <roseg(at)apsis.ch>
2006-09-25 18:24:43 [ FULL ]
On Mon, 2006-09-25 at 09:38 -0400, Roy McMorran wrote:[...]

So if I understand correctly you say that DELETE has content? I learn
something new everyday.

We'll change the next release to ignore content only on HEAD and we'll
see how that behaves...[...]

Re: [Pound Mailing List] pound, webdav, litmus - 4xx response body truncated?
Roy McMorran <mcmorran(at)mdibl.org>
2006-09-25 19:53:32 [ FULL ]
Robert Segall wrote:[...]
Odd yes, but apparently it can have.  Perhaps it would be OK to truncate 
it if Content-Length were reset to zero; I don't know.[...]
Thanks very much for looking into this.
Best wishes,
-r
[...]

Re: [Pound Mailing List] pound, webdav, litmus - 4xx response body truncated?
Roy McMorran <mcmorran(at)mdibl.org>
2006-09-25 20:11:29 [ FULL ]
Robert Segall wrote:[...]
and now it works for me.  Thanks for pointing me in the right direction!
[...]

MailBoxer