error log truncates important infos

Robert Paprocki rpaprocki at
Wed Jun 15 15:53:47 UTC 2016

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>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list