heisters has asked for the wisdom of the Perl Monks concerning the following question:

I'm trying to filter Apache output for a WebDAV client. My filter works as expected with plain HTTP, but when a WebDAV client posts an OPTIONS request, things die: WITH FILTER ON:
OPTIONS /website/trunk/community/ HTTP/1.1 Host: svn.dubya-dev Connection closed by foreign host.
WITH FILTER DISABLED:
OPTIONS /website/trunk/community/ HTTP/1.1 Host: svn.dubya-dev HTTP/1.1 200 OK Date: Mon, 12 Dec 2005 18:30:38 GMT Server: Apache/2.0.54 (Ubuntu) DAV/2 SVN/1.2.0 PHP/5.0.5-2ubuntu1 mod_ +ssl/2.0.54 OpenSSL/0.9.7g mod_perl/2.0.1 Perl/v5.8.7 DAV: 1,2 DAV: version-control,checkout,working-resource DAV: merge,baseline,activity,version-controlled-collection DAV: <http://apache.org/dav/propset/fs/1> MS-Author-Via: DAV Allow: OPTIONS,GET,HEAD,POST,DELETE,TRACE,PROPFIND,PROPPATCH,COPY,MOVE +,LOCK,UNLOCK,CHECKOUT Content-Length: 0 Content-Type: text/plain; charset=UTF-8 Connection closed by foreign host.
This happens even if I program the filter to just pass buckets without doing anything to them. The only way it works is if I completely disable the filter in httpd.conf. Are there steps I need to take to make mod_perl i/o filters compatible with WebDAV? Thanks for any help.

Replies are listed 'Best First'.
Re: mod_perl apache i/o filter borking WebDAV access
by PodMaster (Abbot) on Dec 13, 2005 at 06:31 UTC
    Connection closed by foreign host.
    That doesn't look like death, that looks like apache(or your filter) closed the connection.

    What does your filter look like?
    What do the logs say?

    Are there steps I need to take to make mod_perl i/o filters compatible with WebDAV?
    I don't think you would need to do anything special for WebDAV.

    update: You might try Apache2::DebugFilter - Debug mod_perl and native Apache2 filters.

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

      The logs are unhelpful, but some packet sniffing was. You were right, the filter was closing the connection. It seems that the filter API works fine with GETs, since it's set to by default. However, if you throw any other sort of request at it, it will close unless you return a DECLINED status to Apache, which makes it just pass the request to the next filter. So, you end up needing to specifically deal with every possible request
      # need to specify which options this can't deal with, or it wi +ll bork things. # if a method is undealt with, must pass DECLINED to apache. if ($filter->r->method_number != Apache2::Const::M_GET && $filter->r->method_number != Apache2::Const::M_PUT) { $filter->r->allowed($filter->r->allowed | (1<<Apache2: +:Const::M_GET) | (1<<Apache2::Const::M_PUT)); return Apache2::Const::DECLINED; # otherwise, we do want to do something with this request } else {
      Unfortunately, the only place I could find this documented was under the r->allowed API documentation. Go figure.

      Thanks much for the tips!