diff options
| author | Johan Guldmyr <johan.guldmyr@csc.fi> | 2019-07-04 09:11:44 +0300 |
|---|---|---|
| committer | Johan Guldmyr <johan.guldmyr@csc.fi> | 2019-07-10 20:34:59 +0300 |
| commit | d6b74f5ce9af172d0b3a33234b1489d9af59e5fe (patch) | |
| tree | c052ee775a3012c6f377cffc0140e93907cf829d /releasenotes | |
| parent | 7679e2057a07998fdf1b2cb4a8fd825c20ee469d (diff) | |
| download | oslo-middleware-d6b74f5ce9af172d0b3a33234b1489d9af59e5fe.tar.gz | |
More details when logging 413 Entity Too Large
I spent a few days figuring out what was making the OS-FEDERATION
mapping rules create/update API calls return "413 Entity Too Large"
errors for our CentOS7/haproxy/apache/mod_wsgi/keystone/python2 setup.
To make this a bit easier for future users then I would like to include
max_request_body_size and its value in the response and also log the
error.
Retaining the "Request is too large." bit in the message is intended to
also make it easier to find where the limit is set.
Resulting log error in keystone looks like:
2019-07-04 06:52:13.217789 | ubuntu-bionic | INFO
[oslo_middleware.sizelimit] Request is too large. Larger than
max_request_body_size (114688).
Change-Id: Ic66882afba25222ab8464ac9194c5002c8666db1
Closes-Bug: #1835363
Signed-off-by: Johan Guldmyr <johan.guldmyr@csc.fi>
Diffstat (limited to 'releasenotes')
| -rw-r--r-- | releasenotes/notes/log_max_request_body_size-1835363-6f37946210a100d7.yaml | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/releasenotes/notes/log_max_request_body_size-1835363-6f37946210a100d7.yaml b/releasenotes/notes/log_max_request_body_size-1835363-6f37946210a100d7.yaml new file mode 100644 index 0000000..864d2ed --- /dev/null +++ b/releasenotes/notes/log_max_request_body_size-1835363-6f37946210a100d7.yaml @@ -0,0 +1,4 @@ +--- +other: + - | + Log when max_request_body_size is exceeded. |