error log truncates important infos

B.R. reallfqq-nginx at
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.
*B. R.*

On Wed, Jun 15, 2016 at 5:53 PM, Robert Paprocki <
rpaprocki at> 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>
> wrote:
>> 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
>> problem.
>> What about limiting the fastcgi output to 1024 bytes and appending this
>> info
>> with max 1024 bytes.
>> client:, server:, upstream:
>> "fastcgi://unix:/var/run/", host: "" ,
>> 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.
>> Host
>> 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
>> important
>> fields.
>> Posted at Nginx Forum:
>> _______________________________________________
>> nginx mailing list
>> nginx at
> _______________________________________________
> nginx mailing list
> nginx at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list