error log truncates important infos
reallfqq-nginx at yahoo.fr
Wed Jun 15 17:21:26 UTC 2016
PHP-FPM allows generating its own log files.
The default behavior of having errors sent back the FastCGI tube can be
overridden with proper error logging on PHP-FPM side.
2048 bytes for each line of log is more than enough on the web server side.
Do your homework: read the PHP docs. If you are still struggling, ask some
PHP community to help you through.
On Wed, Jun 15, 2016 at 5:53 PM, Robert Paprocki <
rpaprocki at fearnothingproductions.net> wrote:
> If you're allowing user-generated output to be written directly to your
> logs without any sort of sanitation, you've got bigger problems to worry
> about :p Again, it doesn't really make sense to have your fcgi error sent
> here- why can't your fcgi process log elsewhere, and leaving the nginx
> error log for nginx issues?
> On Wed, Jun 15, 2016 at 6:51 AM, philipp <nginx-forum at forum.nginx.org>
>> Hmm I understand that limitation. But an attacker or a bad application can
>> hide the important information which we need to identify the source of the
>> What about limiting the fastcgi output to 1024 bytes and appending this
>> with max 1024 bytes.
>> client: 127.0.0.1, server: example.com, upstream:
>> "fastcgi://unix:/var/run/php-fpm-example.com.sock:", host: "127.0.0.1" ,
>> request: "GET / HTTP/1.1"
>> [fastcgi - output max 1024][request info: client, server, upstream, host,
>> request - max 1024]
>> This would ensure that client, server and upstream are always provided.
>> and Request can be filled with "user generated" content, so you should put
>> it to the end. This would ensure that an attacker cannot hide the
>> Posted at Nginx Forum:
>> nginx mailing list
>> nginx at nginx.org
> nginx mailing list
> nginx at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx