Running 1.4.1 and using SPDY and SSL extensively (exclusively,
actually).
Seeing a ton (thousands) of errors in the error log, similar to:
2013/05/29 00:22:53 [alert] 25981#0: *8781732 FIXME: chain too big in
spdy
filter: 25516336 while sending to client, client: x.x.x.x, server:
x.y.z,
request: “GET /attachments/113914 HTTP/1.1”, upstream:
“fastcgi://127.0.0.1:9001”, host: “x.y.z”, referrer: “a.b.c”
Names changed to protect the innocent.
What is happening, and how to solve? Users are also reporting that
larger
file downloads are failing with “Network error” or timeout errors,
something
that never happened prior to using SPDY or SSL.
Since I am running an extended validation SSL certificate, I opted to
make all urls on my site SSL, so yes that means attachments are coming thru
SSL
as well.
2013/05/29 00:22:53 [alert] 25981#0: *8781732 FIXME: chain too big in spdy
filter: 25516336 while sending to client, client: x.x.x.x, server: x.y.z,
request: “GET /attachments/113914 HTTP/1.1”, upstream:
“fastcgi://127.0.0.1:9001”, host: “x.y.z”, referrer: “a.b.c”
[…]
Some help?
You have configured too big buffers, that currently cannot be handled in
spdy module. So, you should either decrease the amount of buffers
involved
in request processing, or disable spdy.
It’s hard to tell what buffers you have to tune without knowing of your
configuration, but from the error message I assume that
“fastcgi_buffers”.
What is the maximum amount of the buffer? I could not locate any
documentation on any of this with regards to how it would cause an error
on
SPDY.
And doesn’t “FIXME” indicate this is a bug? Why would it be in the code
otherwise?
I already removed SPDY and the errors went away, as did the problems
users
were experiencing downloading larger files. But I would like to add it
back.
Currently the total amount of operational buffers cannot exceed 2^24 - 1
bytes (in other words must be less than 16 MiB).
I could not locate any documentation on any of this with regards to how it
would cause an error on SPDY.
There is more then one way to trigger this error. The documentation
just
states that the module is experimental.
When you are using an experimental module that implements experimental
protocol draft then you have to be ready for any kind of errors, and not
only caused by the module itself, but in browsers too.
Though you are probably right, and this drawback should be documented
somehow explicitly.
And doesn’t “FIXME” indicate this is a bug? Why would it be in the code
otherwise?
That part of code lacks chain/buffer splitting mechanism as well as the
DATA frame adjusting feature. It will be implemented, but we have no
ETA for this yet.