Re: [1.3 PATCH] another ap_die() issue related to error documents
Roy T. Fielding wrote: client uses HTTP/1.1 to POST a 2MB file, to be handled by a module... module says no way and returns 413... admin has ErrorDocument 413 http://file_too_big.html;... Apache sends back 302 with Location=http://file_too_big.html, but since this is HTTP/1.1, Apache then tries to read the next request and blows up (invalid method in request)... It sends 302? Don't you mean it does a subrequest? I'd hope so. As Cliff says, this is a redirect, not a subrequest. Here's an example from the failure scenario. We send the browser 302 from the POST and we then try to read the body of the POST request as the next request line. [17/Oct/2003:12:13:25 -0400] POST /servlet/Silly HTTP/1.1 302 346 [17/Oct/2003:12:13:25 -0400] -7d32042f1603aa 501 - (If this were Mozilla, we'd also see the GET for the error document here.) And with the patch, much more happiness. [17/Oct/2003:12:20:09 -0400] POST /servlet/Silly HTTP/1.1 302 346 [17/Oct/2003:12:20:10 -0400] GET /413.html HTTP/1.1 200 23
[1.3 PATCH] another ap_die() issue related to error documents
For ErrorDocument nnn http://url;, ap_die() will respond with 302 redirect,
and r-status will be updated to indicate that. But the original error could
have been one that keeps us from being able to process subsequent requests on
the connection. Setting r-status to REDIRECT keeps us from dropping the
connection later, since it hides the nature of the original problem.
Example:
client uses HTTP/1.1 to POST a 2MB file, to be handled by a module...
module says no way and returns 413...
admin has ErrorDocument 413 http://file_too_big.html;...
Apache sends back 302 with Location=http://file_too_big.html, but since this is
HTTP/1.1, Apache then tries to read the next request and blows up (invalid
method in request)...
Depending on browser, you may get something odd. Mozilla still is able to
display the error document after fetching it with GET. IE in HTTP/1.1 mode
displays a Method Not Implemented error message with Invalid method in
request and the first part of the POST body as the method.
(I don't have standalone patch... this is an addition to a patch posted earlier)
@@ -1117,7 +1120,15 @@
* apache code, and continue with the usual REDIRECT handler.
* But note that the client will ultimately see the wrong
* status...
+ *
+ * Also, before updating r-status, we may need to ensure that
+ * the connection is dropped. For example, there may be
+ * unread request body that would confuse us if we try
+ * to read another request.
*/
+if (ap_status_drops_connection(r-status)) {
+r-connection-keepalive = -1;
+}
r-status = REDIRECT;
ap_table_setn(r-headers_out, Location, custom_response);
}
Re: [1.3 PATCH] another ap_die() issue related to error documents
On Friday, October 17, 2003, at 12:27 PM, Jeff Trawick wrote: For ErrorDocument nnn http://url;, ap_die() will respond with 302 redirect, and r-status will be updated to indicate that. But the original error could have been one that keeps us from being able to process subsequent requests on the connection. Setting r-status to REDIRECT keeps us from dropping the connection later, since it hides the nature of the original problem. Example: client uses HTTP/1.1 to POST a 2MB file, to be handled by a module... module says no way and returns 413... admin has ErrorDocument 413 http://file_too_big.html;... Apache sends back 302 with Location=http://file_too_big.html, but since this is HTTP/1.1, Apache then tries to read the next request and blows up (invalid method in request)... It sends 302? Don't you mean it does a subrequest? I'd hope so. Anyway, +1 to the patch. Roy
Re: [1.3 PATCH] another ap_die() issue related to error documents
On Fri, 17 Oct 2003, Roy T. Fielding wrote: It sends 302? Don't you mean it does a subrequest? I'd hope so. Anyway, +1 to the patch. I always thought it did a 302 if the errordocument started with http:// (ie, was possibly external), but did a subrequest if it did not start with http:// . That is, in fact, the documented behavior: http://httpd.apache.org/docs/mod/core.html#errordocument --Cliff
