Here's some notes about this bug:
After plowing through some Apache source, I think I have found the root
of the problem.
I have been examining the Apache stock 2.0.44 source.
If we look at httpd-2.0.44/modules/dav/mod_dav.c line 3955, we have:
r->status = HTTP_OK;
ap_set_content_type(r, DAV_XML_CONTENT_TYPE);
/* run report hook */
if ((err = (*vsn_hooks->deliver_report)(r, resource, doc,
r->output_filters)) != NULL)
{
/* NOTE: we're assuming that the provider has not generated any
content yet! */
return dav_handle_err(r, err, NULL);
}
Notice the status gets set to 200, but in the case of this bug,
deliver_report generates an error.
dav_handle_err() does update the status through dav_error_response_tag()
to 404.
However, before we return from our deliver report handler (in this case
it is dav_svn__update_report ) we call ap_fflush().
Somehow, this call to ap_fflush() is sending our headers, before we have
returned and called dav_handle_err() to update the status.
And upon further review:
The output_filters that are passed to dav_svn__update_report contains a
filter for the header.
Therefore, when ap_fflush is called, ap_http_header_filter gets called
which builds the header and puts it on the wire, before the status is
updated.
This is why that comment that I have posted above:
/* NOTE: we're assuming that the provider has not generated any content
yet! */
is listed. Because if you generate content and flush it before you
return, you risk a wrong header status code, as is happening with this
bug.
And of course, at the termination of ap_http_header_filter it removes
itself from the filter list, so headers won't get sent again later.
I'm not sure what the best way to go about fixing this problem is, since
we generate content in the report function.
--James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 28 02:35:26 2003