Request body not present in PHP / many tags are useless

I’ve noticed the default setup for PHP Exceptions is pretty bland, and I’m trying to improve that, but it seems quite… hard. How can I improve the default reports changing the settings?

  1. Many of the tags displayed are pretty much useless:
  • how can it tell me the browser is “Other” if there’s a clear User-Agent header on the request?
  • device and os are also useless - I would like to remove those as they don’t make much sense in a browser environment… unless Sentry sniffs out the correct values from the UA - what it seems it can’t do right now.
  • logger doesn’t seem to be useful at all, but it seems important, so I didn’t try to override, even though the documentation doesn’t explain what that is.
  • finally, I can’t quite “override” the default value for tags; in the end, setting a browser tag in the setup creates a report with two tags, one with what I wrote and another one with “Other” - this one seems to be coming from the reporting context? But then, how could the context force in a “default” value that’s actually empty (other has no real meaning, it’s just a placeholder word).
  1. It’s hard to debug requests as it’s only storing headers and URL. Where are my POST fields, the request body? I tried to manually add that through send_callback but it made no difference, the Exception details are still the same - even the raw payload Sentry received for those with altered callback seems to be the same.
    I noticed the Ruby SDK includes details on how to enable/disable POST payload, but that doesn’t seem to exist on the PHP SDK.

  2. Finally, would be dat more useful if the rest of the exception fields were shown as well. I can’t see the exception code, nor other fields from the object - those fields are used in my application to display error details. Sentry should store some sort of serialized version of the Exception, at least, instead of simply the stack trace and its title.

This is how I’m configuring Sentry right now:

/** @var bool $call_existing This defines if Raven/Sentry should call the original handlers after errors reporting */
$call_existing = true;

$raven = (new Raven_Client('https://**:**', [
    'release' => trim(`git rev-parse --short HEAD`),
    'environment' => APPLICATION_ENV,
    'app_path' => APPLICATION_PATH,
    'prefixes' => [dirname(APPLICATION_PATH)],

    //most of the shown tags are useless, so I'm trying to override them here
    'tags' => [
        'browser' => $_SERVER['HTTP_USER_AGENT'] ?? 'Unknown',
        'device' => 'none',
        'os' => 'none'

    //the request details only include URL and Headers, so I'm trying to add body and POST fields
    'send_callback' => function(array &$data) {
        $data['request']['body'] = file_get_contents('php://input');
        if ($_SERVER['REQUEST_METHOD'] == 'POST') {
            $data['request']['fields'] = $_POST;
        return $data;

$handler = (new Raven_ErrorHandler($raven))

Regarding the tags, we should fix the issue that you cant override the auto generated tags. Whether they’re useful or correct becomes another issue, but often we end up not being able to fully get user agents – we’re using a library from Google that sometimes isn’t kept up well.

In terms of the HTTP data, I’m not sure why you’re sending the values you are, but we dont allow arbitrary parameters for most things. For example, to send the request body you would use the ‘data’ attribute, and we generally expect it in the format of a string:

I could fix the HTTP data sent as specified in that docs. Thanks!

However, I did notice that data sanitization is heavier on the Sentry server… I’ve inspected Raven_SanitizeDataProcessor and noticed this is the final result of the data in a failed auth call (because appname is empty, in this case):

However, all I get in the Sentry panel is [Filtered]. Is it possible to configure it to be more permissive and actually allow me to see what fields were submitted and at least if they were filled or not?

These controls all exist within the project’s settings on the server.

1 Like

Thanks! I’m not the project manager so I didn’t had access to the settings screen, I didn’t know that exists :slight_smile:

We’ve made a fix on the server os the auto generated tag integrations will no longer override user tags – release/environment/etc will still take priority though. We’re also forcefully disallowing multiple values per key now.

Thanks man :slight_smile:

Igor Santos
Desenvolvedor web @ Toptal - the top 3% of freelancer talent