Buglet in mod_dav?
From: <cmpilato_at_collab.net>
Date: 2001-09-28 20:03:12 CEST
Re: Issue #496
Karl saw a problem, and Ben started looking at it, and I've tracked it
I'm looking at mod_dav.c:dav_method_merge(), and I see this:
----
/* Initialize these values for a standard MERGE response. If the MERGE
is going to do something different (i.e. an error), then it must
return a dav_error, and we'll reset these values properly. */
r->status = HTTP_OK;
r->status_line = ap_get_status_line(HTTP_OK); /* ### needed? */
r->content_type = "text/xml";
/* ### should we do any preliminary response generation? probably not,
### because we may have an error, thus demanding something else in
### the response body. */
/* Do the merge, including any response generation. */
if ((err = (*vsn_hooks->merge)(resource, source_resource,
no_auto_merge, no_checkout,
prop_elem,
r->output_filters)) != NULL) {
/* ### is err->status the right error here? */
err = dav_push_error(r->pool, err->status, 0,
apr_psprintf(r->pool,
"Could not MERGE resource \"%s\" "
"into \"%s\".",
ap_escape_html(r->pool, source),
ap_escape_html(r->pool, r->uri)),
err);
return dav_handle_err(r, err, NULL);
}
----
dav_handle_err() is called with a NULL dav_response, the error
returned by the server is the value of r->status, which at this point
is still HTTP_OK.
Greg (someone?), under what conditions should r->status actually be
stuffed with err->status? Is this a bug in mod_dav, or should our
client be parsing the HTTP response for a *real* error code?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:42 2006
|
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.