Bug 1377520 - Setting ErrorDocument 413 to a remote URL does not work for the requests are marked as redirect
Summary: Setting ErrorDocument 413 to a remote URL does not work for the requests are ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: httpd
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Luboš Uhliarik
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 1298243 1420851
TreeView+ depends on / blocked
 
Reported: 2016-09-20 02:00 UTC by Masafumi Miura
Modified: 2019-12-16 06:49 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-26 13:52:31 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Masafumi Miura 2016-09-20 02:00:28 UTC
### Description of problem:

A customer would like to use this Apache httpd server like a sorry server but they do not want to put any contents on the server. So, they use RedirectMatch for most requests to send a redirection. Also they want to configure to send a redirection to specific URL for 413 "Request Entity Too Large", which is different from the URL specified with RedirectMatch. But setting ErrorDocument 413 to a remote URL does not work for the requests are marked as redirect. 


### Version-Release number of selected component (if applicable):

httpd-2.4.6-40.el7_2.4.x86_64


### How reproducible:

Anytime.


### Steps to Reproduce:

1. Configure LimitRequestBody, ErrorDocument for 413 and RedirectMatch:

    LimitRequestBody 100
    ErrorDocument 413 http://www.example.com/error413.html
    <Location />
    RedirectMatch temp ^(?!/server-status$) http://www.example.com/index.html
    </Location>

2. Prepare a test file which is larger than LimitRequestBody:

    dd if=/dev/zero of=/tmp/testfile bs=1 count=101

3. Sent a POST request with the generated file:

    curl -X POST -vs -T /tmp/testfile http://127.0.0.1/index.html


### Actual results:

An original error page is shown and the message "error was encountered while trying to use an ErrorDocument to handle the request" is shown inside the error page.

~~~
< HTTP/1.1 413 Request Entity Too Large
< Date: Thu, 15 Sep 2016 01:36:53 GMT
< Server: Apache
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>413 Request Entity Too Large</title>
</head><body>
<h1>Request Entity Too Large</h1>
The requested resource<br />/hoge<br />
does not allow request data with POST requests, or the amount of data provided in
the request exceeds the capacity limit.
<p>Additionally, a 413 Request Entity Too Large
error was encountered while trying to use an ErrorDocument to handle the request.</p>
</body></html>
~~~

### Expected results:

Redirected to the specified remote URL.


### Additional info:

Same issue is reproducible with the latest community version (httpd-2.4.23).


### Possible Workaround:

Specify a literal string (a simple error message) to ErrorDocument. (For example: ErrorDocument 413 "413 Request Entity Too Large" ) But this is generally not what the customer want.

Or put a html page which performs a redirection in the client side, then use RewriteRule to handle requests with the html page like the following. "ErrorDocument 413 <remote-url>" works with this configuration:

 * redirect.html:

~~~
<head>
<meta http-equiv="refresh" content="0; URL=http://example.com/">
<script type="text/javascript">
    location.replace("http://example.com")
</script>
<title>Redirect</title>
</head>
~~~

 * mod_rewrite setting:

~~~
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/server-status$
RewriteRule ^/(.*) /redirect.html
~~~

Comment 3 Kyle Walker 2019-06-26 13:52:31 UTC
Due to the originating report of this issue being closed for an extended period of time, and no further reports of this behaviour, I am closing this bug at this time in order to focus our efforts on higher priority issues.

Please reopen if a further occurrence is encountered.


Note You need to log in before you can comment on or make changes to this bug.