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,
-- 

Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran(at)mdibl.org

On Thu, 2006-09-21 at 14:31 -0400, Roy McMorran wrote:
> 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,

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?
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

Robert Segall 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?
>   
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

-- 

Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran(at)mdibl.org

On Mon, 2006-09-25 at 09:38 -0400, Roy McMorran wrote:
> Robert Segall 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?
> >   
> 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.

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...
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

Robert Segall wrote:
> So if I understand correctly you say that DELETE has content? I learn
something new everyday.
>   
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.
> We'll change the next release to ignore content only on HEAD and we'll
> see how that behaves...
>   
Thanks very much for looking into this.
Best wishes,
-r

-- 

Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran(at)mdibl.org

Robert Segall wrote:
> We'll change the next release to ignore content only on HEAD and we'll
> see how that behaves...
>   
>
OK, I tried that here (basically commenting out lines 531-533 in http.c) 
and now it works for me.  Thanks for pointing me in the right direction!

-- 

Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran(at)mdibl.org