Our team ran into a bug with the current code in pound (2.0.6) that caused
commits to an SVN repository to fail through Apache.  This was demonstrated
using both subversion command line client and the TortoiseSVN client.

 

Apparently, the OPTIONS command required authentication and somehow this was
not getting passed back to the client causing a hang.

 

Client ERROR:

 

Error: Commit failed (details follow):  

Error: OPTIONS request failed on '/svn/incubator'  

Error: OPTIONS of '/svn/incubator': Could not read response body: Secure
connection truncated (https://server.name.withheld)  

 



 

 

Pound log:

Jun  6 08:45:26 static-host pound: starting...

Jun  6 08:46:08 static-host pound: 68.66.14.5 OPTIONS /svn/incubator
HTTP/1.1 - HTTP/1.1 401 Authorization Required (192.168.2.79:8000)

 

Apache Access Log:

192.168.2.79 - user [06/Jun/2006:08:44:41 -0400] "PROPFIND /svn/incubator
HTTP/1.1" 207 657 "-" "SVN/1.3.1 (r19032) neon/0.25.4"

192.168.2.79 - user [06/Jun/2006:08:44:42 -0400] "PROPFIND
/svn/incubator/!svn/vcc/default HTTP/1.1" 207 409 "-" "SVN/1.3.1 (r19032)
neon/0.25.4"

192.168.2.79 - user [06/Jun/2006:08:44:42 -0400] "PROPFIND
/svn/incubator/!svn/bln/24 HTTP/1.1" 207 462 "-" "SVN/1.3.1 (r19032)
neon/0.25.4"

192.168.2.79 - user [06/Jun/2006:08:44:42 -0400] "PROPFIND /svn/incubator
HTTP/1.1" 207 657 "-" "SVN/1.3.1 (r19032) neon/0.25.4"

192.168.2.79 - user [06/Jun/2006:08:44:43 -0400] "PROPFIND
/svn/incubator/!svn/vcc/default HTTP/1.1" 207 409 "-" "SVN/1.3.1 (r19032)
neon/0.25.4"

192.168.2.79 - user [06/Jun/2006:08:44:43 -0400] "PROPFIND
/svn/incubator/!svn/bln/24 HTTP/1.1" 207 462 "-" "SVN/1.3.1 (r19032)
neon/0.25.4"

192.168.2.79 - user [06/Jun/2006:08:44:43 -0400] "PROPFIND /svn/incubator
HTTP/1.1" 207 657 "-" "SVN/1.3.1 (r19032) neon/0.25.4"

192.168.2.79 - user [06/Jun/2006:08:44:43 -0400] "REPORT
/svn/incubator/!svn/vcc/default HTTP/1.1" 200 263492 "-" "SVN/1.3.1 (r19032)
neon/0.25.4"

192.168.2.79 - - [06/Jun/2006:08:46:08 -0400] "OPTIONS /svn/incubator
HTTP/1.1" 401 - "-" "SVN/1.3.1 (r19032) neon/0.25.4"

 

 

Commenting out the OPTIONS clause on line 715 fixed the problem:

 

  /* Other WebDAV requests may also result in no content, but we don't know
- Microsoft won't tell us */

  no_cont = !(strncasecmp(request + matches[1].rm_so, "LOCK",
matches[1].rm_eo - matches[1].rm_so)

          && strncasecmp(request + matches[1].rm_so, "UNLOCK",
matches[1].rm_eo - matches[1].rm_so)

          && strncasecmp(request + matches[1].rm_so, "DELETE",
matches[1].rm_eo - matches[1].rm_so));

          //&& strncasecmp(request + matches[1].rm_so, "OPTIONS",
matches[1].rm_eo - matches[1].rm_so));

        } else {

 

 

--

DLR

On Tue, 2006-06-06 at 12:51 -0700, Darren Rush wrote:
>   /* Other WebDAV requests may also result in no content, but we don't know
> - Microsoft won't tell us */
> 
>   no_cont = !(strncasecmp(request + matches[1].rm_so, "LOCK",
> matches[1].rm_eo - matches[1].rm_so)
> 
>           && strncasecmp(request + matches[1].rm_so, "UNLOCK",
> matches[1].rm_eo - matches[1].rm_so)
> 
>           && strncasecmp(request + matches[1].rm_so, "DELETE",
> matches[1].rm_eo - matches[1].rm_so));
> 
>           //&& strncasecmp(request + matches[1].rm_so, "OPTIONS",
> matches[1].rm_eo - matches[1].rm_so));
> 
>         } else {

So OPTIONS may have content? Good to know - this goes into 2.1. Many
thanks for tracking it down.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904