Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: domain of rooneg@gmail.com designates
 64.233.184.238 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth;
        b=Kp1WQHC8f1gVi7pf/W1WXREGIyBUNZULQnnI9+LkD9KA4rCb1IWXxKnxt5Y26uH40s3gxM7c3573nxhHrJgW6ayuudC7vx3zIkfkyd5F/EPBdVKs6O8b2q2xPvmaaRKczFSI+T2bKIicAXilOn6mpgNYieh6pn3G/6tOmmHNBnA=
Message-ID: <7edfeeef0605191536q5401a7f6kff078ff61819f82@mail.gmail.com>
Date: Fri, 19 May 2006 15:36:30 -0700
From: "Garrett Rooney" <rooneg@electricjellyfish.net>
Sender: rooneg@gmail.com
To: "HTTPD Dev List" <dev@httpd.apache.org>
Subject: mod_dav spamming over r->status
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

So I've got this module that works as an input filter.  It sits in
front of mod_dav_svn and parses incoming REPORT requests, and when it
determines that something is wrong it sets r->status and
r->status_line and errors out by returning APR_EGENERAL.

In HTTPD 2.0.x this works as I expect, the status line I set is sent
back to the user.  In HTTPD 2.2.x I just get a generic error (400 Bad
Request).  This seems kind of odd, so I looked into it.

It turns out that the source of the difference is that in 2.2.1 we
added code that sanity checks r->status and r->status_line, and only
uses r->status_line if the number at the beginning matches r->status.
It turns out that despite the fact that I set both r->status and
r->status_line at the same time, by the time it hits
basic_http_header_check in http_filters.c they're no longer the same.

So where is r->status getting spammed?  Well, it's actually deep in
mod_dav.  We call ap_xml_parse_input, which ends up causing our filter
to get called and  the underlying error gets returned.  This means
that HTTP_BAD_REQUEST gets returned up the stack.  That eventually
gets passed into ap_die, and in ap_die, which does the actual setting
of r->status to HTTP_BAD_REQUEST, which means our r->status and
r->status_line are out of sync, which means the status line gets
ignored.

So my first instinct is to fix this in the XML parsing code.  If we
get to the error case and r->status is already set to something
interesting, we should return that instead of our default
HTTP_BAD_REQUEST.  Does that make sense?

-garrett