You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 2001/03/27 19:12:19 UTC
[PATCH] Allow ErrorDocument even on HTTP syntax errors (was: Re: Bug (?)
in 1.3)
Here is a patch that will fix this, without breaking anything
else as far as I can tell. ErrorDocument 400 will be honoured
regardless of the cause of the HTTP_BAD_REQUEST condition.
For 1.3.next consideration.
Index: src/main/http_protocol.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
retrieving revision 1.300
diff -u -r1.300 http_protocol.c
--- src/main/http_protocol.c 2001/03/09 10:10:26 1.300
+++ src/main/http_protocol.c 2001/03/27 17:07:57
@@ -1119,12 +1119,14 @@
ap_keepalive_timeout("read request line", r);
if (!read_request_line(r)) {
+ int rstatus;
+ rstatus = r->status;
ap_kill_timeout(r);
- if (r->status == HTTP_REQUEST_URI_TOO_LARGE) {
-
+ if (rstatus == HTTP_REQUEST_URI_TOO_LARGE) {
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
"request failed: URI too long");
- ap_send_error_response(r, 0);
+ r->status = HTTP_OK;
+ ap_die(rstatus, r);
ap_log_transaction(r);
return r;
}
@@ -1135,9 +1137,12 @@
get_mime_headers(r);
ap_kill_timeout(r);
if (r->status != HTTP_REQUEST_TIME_OUT) {
+ int rstatus;
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
"request failed: error reading the headers");
- ap_send_error_response(r, 0);
+ rstatus = r->status;
+ r->status = HTTP_OK;
+ ap_die(rstatus, r);
ap_log_transaction(r);
return r;
}
@@ -1146,6 +1151,7 @@
ap_kill_timeout(r);
if (r->header_only) {
+ int rstatus;
/*
* Client asked for headers only with HTTP/0.9, which doesn't send
* headers! Have to dink things just to make sure the error message
@@ -1155,8 +1161,9 @@
"client sent invalid HTTP/0.9 request: HEAD %s",
r->uri);
r->header_only = 0;
- r->status = HTTP_BAD_REQUEST;
- ap_send_error_response(r, 0);
+ rstatus = r->status;
+ r->status = HTTP_OK;
+ ap_die(rstatus, r);
ap_log_transaction(r);
return r;
}
@@ -1190,7 +1197,10 @@
"(see RFC2616 section 14.23): %s", r->uri);
}
if (r->status != HTTP_OK) {
- ap_send_error_response(r, 0);
+ int rstatus;
+ rstatus = r->status;
+ r->status = HTTP_OK;
+ ap_die(rstatus, r);
ap_log_transaction(r);
return r;
}
@@ -1213,12 +1223,13 @@
r->expecting_100 = 1;
}
else {
- r->status = HTTP_EXPECTATION_FAILED;
+ int rstatus;
+ rstatus = HTTP_EXPECTATION_FAILED;
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_INFO, r,
"client sent an unrecognized expectation value of "
"Expect: %s", expect);
- ap_send_error_response(r, 0);
- (void) ap_discard_request_body(r);
+ r->status = HTTP_OK;
+ ap_die(rstatus, r);
ap_log_transaction(r);
return r;
}
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
the only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!
Re: [PATCH] Allow ErrorDocument even on HTTP syntax errors (was: Re: Bug
(?) in 1.3)
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"Roy T. Fielding" wrote:
>
> Nope, -1. This won't work because those are conditions tested
> before the request record contains elements needed by die and
> its subsequently called subroutines.
I *did* test these cases, you know..
> In any case, it is not possible to send custom responses for
> every single possible error condition, so we've got better
> things to do than fix this problem in 1.3.
Please do not tell me how I should be spending my time..
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
the only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!
Re: [PATCH] Allow ErrorDocument even on HTTP syntax errors (was: Re: Bug
(?) in 1.3)
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"Roy T. Fielding" wrote:
>
> In any case, it is not possible to send custom responses for
> every single possible error condition, so we've got better
> things to do than fix this problem in 1.3.
Then one of those better things ought to be documenting the
cases in which custom error responses will not work.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
the only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!
Re: [PATCH] Allow ErrorDocument even on HTTP syntax errors (was: Re: Bug (?) in 1.3)
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Tue, Mar 27, 2001 at 12:12:19PM -0500, Rodent of Unusual Size wrote:
> Here is a patch that will fix this, without breaking anything
> else as far as I can tell. ErrorDocument 400 will be honoured
> regardless of the cause of the HTTP_BAD_REQUEST condition.
>
> For 1.3.next consideration.
Nope, -1. This won't work because those are conditions tested before
the request record contains elements needed by die and its subsequently
called subroutines. In any case, it is not possible to send custom
responses for every single possible error condition, so we've got better
things to do than fix this problem in 1.3.
In order to make this work [in 2.0], the error sending code should be
replaced by something that doesn't assume it is coming at the end
of a normal request. Instead, it should be an internal redirect to
a directory of template files (301.htm, 404.htm, etc.) that can be
filtered to include the specific error information (properly encoded,
of course) based on notes given to the internal redirect. That would
separate the read-status of the initial request from the error response
handling.
....Roy