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.orgReceived 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.