Request Entity Too Large

Recently started getting the follow error, without any explicit change to Raven or Sentry configuration. Google results are unrevealing. Is there something known that can cause this?

Any proper ways of logging more fully the original AttributeError, which caused the Sentry error, besides disabling Sentry?

INFO:werkzeug:172.17.42.1 - - [29/Apr/2015 01:02:51] "POST / HTTP/1.1" 500 -
ERROR:sentry.errors:Unable to reach Sentry log server: HTTP Error 413: Request Entity Too Large (url: https://app.getsentry.com/api/39671/store/, body: b'<html>\r\n<head><title>413 Request Entity Too Large</title></head>\r\n<body bgcolor="white">\r\n<center><h1>413 Request Entity Too Large</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n')
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/site-packages/raven/transport/threaded.py", line 159, in send_sync
    super(ThreadedHTTPTransport, self).send(data, headers)
  File "/usr/local/lib/python3.4/site-packages/raven/transport/http.py", line 49, in send
    ca_certs=self.ca_certs,
  File "/usr/local/lib/python3.4/site-packages/raven/utils/http.py", line 62, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/local/lib/python3.4/urllib/request.py", line 461, in open
    response = meth(req, response)
  File "/usr/local/lib/python3.4/urllib/request.py", line 571, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/local/lib/python3.4/urllib/request.py", line 499, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python3.4/urllib/request.py", line 433, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python3.4/urllib/request.py", line 579, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 413: Request Entity Too Large
ERROR:sentry.errors:Failed to submit message: "AttributeError: 'dict' object has no attribute 'encode'"

Is this getsentry.com or are you hosting it yourself?

Getsentry.com

On Tuesday, April 28, 2015, David Cramer notifications@github.com wrote:

Is this getsentry.com or are you hosting it yourself?

—
Reply to this email directly or view it on GitHub
#604 (comment)
.

This would mean the packet is very large. I think we should do something on our end around logging, but it's a little complicated. We definitely should log a reasonable version of the message (beyond just what we give you here). Unfortunately without changes to the client I don't have a great answer.

Hm, ok. What composes the packet? I am working with a number large files,
perhaps one is getting itself attached to the error report somehow, and we
definetly wouldn't want or need that.

Happy to test out or make changes as advised.

On Tuesday, April 28, 2015, David Cramer notifications@github.com wrote:

This would mean the packet is very large. I think we should do
something on our end around logging, but it's a little complicated. We
definitely should log a reasonable version of the message (beyond just what
we give you here). Unfortunately without changes to the client I don't have
a great answer.

—
Reply to this email directly or view it on GitHub
#604 (comment)
.

Closing this out as it was (potentially) resolved elsewhere

nice, thank you

It was? I'm still experiencing 413 responses from getsentry.com when POSTing a 5.3MB payload.
Perhaps you could log something about the 413 in Sentry when this happens so one knows an error occurred. Took some digging in syslogs to find the error.

@jmagnusson

@jmagnusson do you see this in the 5.6 release?

Yup, still. Sentry responded with an error: HTTP Error 413: Request Entity Too Large (url: https://app.getsentry.com/api/.../store/)

So this is still an issue, although thanks to your help earlier/elsewhere, it is being logged sufficiently locally.

A believe a couple actions should be taken:

Upon receiving a too large entity, the server should log a proxy exception, alerting the user that an event happened which was un-capturable. This would prevent silent doom.
An API should be devised to all the automatic or selective truncation of large strings when errors are thrown. E.g., if I have an attribute error on a dictionary with a large string key, in many cases I don't have any need to know the contents of that key, beyond perhaps the first 100 chars to indicate its further contents.

Seeing this as well from the error dump of a complex elasticsearch query.

It still hasn't been resolved?

Just got hit by this issue (not related to the python lib though). What's the maximum body size allowed by sentry?

Most of the time this is due to the configuration of the server. If this is getsentry.com the request limit is extremely high and there's no way you should be hitting it. If you are, then it likely means that the client side variable trimming isn't working correctly, or has been re-configured to send data that is too large.

are you still experiencing this?

As of 8 days ago I was. See my previous comment.
I can provide you more details but in private in case I do something silly that reveals too much.

I meant as in right now. We made changes yesterday which should have reduced the impact.

@dcramer

@dcramer Yes, but because I don't know how to corner this, here's what I did:
(Note: I'm doing this on a side-project so attention is restricted)

I injected some print in site-packages/raven/utils/http.py towards the end:

-   return opener.open(url, data, timeout)
+   try:
+        return opener.open(url, data, timeout)
+   except Exception:
+        print("EXCEPTION!!!!", url, url.get_full_url(), data[:1000])
+        raise

Then I hawkishly watch my uwsgi log file and I get this:

EXCEPTION!!!! <urllib.request.Request object at 0x7fd9103efb38> https://sentry.io/api/196160/store/ b'x\x9c\xec\xbdiw\xe2H\xb20\xfcW\xd4\xf5~p\xd5)\x97\xd9\xb7\xea;\xb7\x0f\x8b0xe\xf3\x82\xa7\xe6\xf4MP"\xc9\x08\t$
Sentry responded with an error: HTTP Error 413: Request Entity Too Large (url: https://sentry.io/api/196160/store/)
Traceback (most recent call last):
  File "/var/lib/django/songsearch/venv/lib/python3.5/site-packages/raven/transport/threaded.py", line 165, in send_sync
    super(ThreadedHTTPTransport, self).send(url, data, headers)
  File "/var/lib/django/songsearch/venv/lib/python3.5/site-packages/raven/transport/http.py", line 43, in send
    ca_certs=self.ca_certs,
  File "/var/lib/django/songsearch/venv/lib/python3.5/site-packages/raven/utils/http.py", line 67, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.5/urllib/request.py", line 472, in open
    response = meth(req, response)
  File "/usr/lib/python3.5/urllib/request.py", line 582, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.5/urllib/request.py", line 510, in error
    return self._call_chain(*args)
  File "/usr/lib/python3.5/urllib/request.py", line 444, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.5/urllib/request.py", line 590, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 413: Request Entity Too Large
['OSError: write error']

@peterbe

@peterbe any chance you could try to capture data to a file and email that to david at sentry.io? This might be something where its genuinely creating a gigantic packet. The SDK is supposed to limit the length of everything, but thats not always been true.

Aside, you can sign with PGP key if you're concerned: https://sentry.io/security/

@dcramer

@dcramer I don't think it needs to be signed up I've written a little hack now to generate these data files. I'll email you one if I get another exception. At the time of writing I haven't had one happen in a while.

The problem in this specific example is breadcrumbs are not truncating log messages. In this case theres an elasticsearch logger (not sure if yours or the official library), and an unbelievably large debug message which seems to be the full payload being inserted.

Stock Django 1.11 with no fancy logging specifically for elasticsearch_dsl. I appreciate that sometimes Elasticsearch barfs but there should still be an error sent to Sentry. I do use this little snippet for calling elasticsearch_dsl:

from elasticsearch.exceptions import (
    ConnectionTimeout,
    ConnectionError,
    TransportError,
    NotFoundError,
)

_es_operational_exceptions = (
    ConnectionTimeout,
    ConnectionError,
    TransportError,
)


def es_retry(callable, *args, **kwargs):
    sleep_time = kwargs.pop('_sleep_time', 1)
    attempts = kwargs.pop('_attempts', 10)
    verbose = kwargs.pop('_verbose', False)
    try:
        return callable(*args, **kwargs)
    except _es_operational_exceptions as exception:
        if attempts:
            attempts -= 1
            if verbose:
                print("ES Retrying ({} {}) {}".format(
                    attempts,
                    sleep_time,
                    exception
                ))
            time.sleep(sleep_time)
        else:
            raise

I don't see those ES Retrying prints in the uwsgi logs.

@peterbe

@peterbe sorry I should have been clear that i was intending to fix it, but the behavior (of using debug messages to log e.g. raw packets) is poor in general. ES certainly isnt alone in that.

any chance of deploying a new version of raven which includes the fix? This issue has been a real pain for a long time for us and we really want to try this fix.

@d-dorazio will be out by tomorrow.

I am still experiencing this issue even after updating to version 6.10.0.

I am having this error working with next.js and "@sentry/react": version 5.20.1 with the default configuration of React

@davidpaley

For reference, @davidpaley apparently solved his problem here: getsentry/sentry-javascript#2798

Navigation Menu

Repository navigation

Request Entity Too Large #604

28 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Request Entity Too Large #604

Description

Activity

dcramer commented on Apr 29, 2015

pehrlich commented on Apr 29, 2015

dcramer commented on Apr 29, 2015

pehrlich commented on Apr 29, 2015

dcramer commented on Apr 30, 2015

pehrlich commented on Apr 30, 2015

jacobsvante commented on Aug 27, 2015

dcramer commented on Aug 27, 2015

jacobsvante commented on Aug 28, 2015

pehrlich commented on Sep 23, 2015

jhubert commented on Mar 9, 2016

jacobsvante commented on Mar 9, 2016

ruimarinho commented on Apr 11, 2016

dcramer commented on Apr 11, 2016

28 remaining items

peterbe commented on Feb 2, 2018

dcramer commented on Feb 2, 2018

peterbe commented on Feb 2, 2018

dcramer commented on Feb 2, 2018

dcramer commented on Feb 2, 2018

peterbe commented on Feb 2, 2018

dcramer commented on Feb 2, 2018

peterbe commented on Feb 2, 2018

dcramer commented on Feb 2, 2018

danieledapo commented on Feb 9, 2018

ashwoods commented on Feb 9, 2018

ryechus commented on May 5, 2020

davidpaley commented on Aug 4, 2020

Empact commented on Nov 6, 2020

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions