On 21 October 2013 23:05, Jeff Jordan <[email protected]> wrote:
> We are running pound 2.5 on debian squeeze and are seeing a large number
> of "e500 can't read header" messages in the logs.
>
> (7f2b4151c700) e500 can't read header
> (7f2b42493700) e500 can't read header
> (7f2b25412700) e500 can't read header
> (7f2b339a6700) e500 can't read header
>
> We have not been able to reproduce the error. All of our customers that
> have reported it have been able to fix it by clearing their browser cache.
> Can anyone tell us what this error means and if there something we can do
> on our end to fix it.
>
"can't read header" is logged LOG_WARNING.
If you're not also seeing "line too long" (logged LOG_NOTICE),
double check your syslog to make sure you're logging that as
expected ("logger" is handy for this, e.g. logger -p daemon.info).
If you *are* seeing "line too long", then some clients are sending
header lines longer than MAX_BUF (4096 default, unchanged by
Debian). This can be increased at compile time, I've only ever
needed to increase it for long URLs, not long headers.
If clearing the cache fixes it, then it may be a problematic cookie
constantly growing.
If you are *not* seeing "line too long" then the most likely cause
is malformed headers (missing trailing \r or \n), or clients dropping
the connections. You may need to capture some traffic to confirm
or deny this (use the pthread id to track down likely offenders).
Finally, and less likely, Debian modify the default build options
to include buffer exploit mitigations relro and noexecstack. Usually
problems seen are either build/link failures, or instability (segfault).
There are no Pound patches added by Debian on squeeze, AFAICT.
C.
