I have been piloting the SPDY patch on a separate web server pointing to
an
existing HTTP backend.
With just myself using this pilot web server, occasionally static
resources
such as css or images are not loading in Firefox (usually when pressing
F5
to reload a page)
Have done a bit of digging and have learnt this so far:
When issue occurs in Firefox, access log is showing 499 errors for the
missing static resources (when it should be 304)
Refreshing the page will eventually load the resources (and they will
show
304 in the access log)
If I turn off the proxy cache for these static resources, the issue
stops
If I turn off SPDY, the issue stops.
The issue obviously doesn’t occur on the production web server running
Nginx
1.2.x
Has this been seen before, or can you think of any reason why this might
happen?
I don’t normally use Chrome but have also witnessed this once in Chrome,
so
I don’t think it’s browser specific (however will try to get more
confidence
of this).
And the issue was fixed shortly afterwards in the 1.3.x branch.
I’m now seeing the same issue again (static items coming from proxy
cache +
SPDY not displaying).
However this time, the log does not show 499 error anymore… it just
shows
successful 304. However, looking at firefox web console, the first few
static items come back as 304 without problems, then the next set of
static
items come back with no response at all… (no response header, no body).
The setup looks like this:
Firefox → Nginx 1.3.15 → HAproxy → Tomcat
Has this bug crept back in, or is this a new one? Also reproduced on
1.3.13.
Can’t seem to reproduce the issue if I take out HAproxy in the middle
though.
So perhaps I shouldn’t have reused my existing topic and confused
things,
sorry!
I only did so because the symptom is exactly the same as the issue I
originally reported (SOME static content served from proxy cache
occasionally doesn’t make it to Firefox when using SPDY). If you
disable
either SPDY or the proxy cache the problem stops happening.
The originally reported problem stopped occurring after a fix was
implemented, but now I’m seeing it again since I put haproxy as the
upstream
(to get enhanced health checks etc).
The difference this time is that I’m not seeing the 499 errors (or 444)
in
the nginx log. I’m not returning 444 (via config) in these scenarios
either.
So you can see that around the time it loads the 5th image things go
wrong
and the 5th onward images all have no content. Firefox detail shows no
response headers/content for the 5th image onward.
The Haproxy and Nginx logs show 304 successfully for all of these
requests,
so I guess the connection is dropped somewhere and Nginx isn’t picking
it up
and still thinks it worked fine.
Any suggestions on how to proceed further on this? Happy to provide
specific details/logs via email if required.
The originally reported problem stopped occurring after a fix was
GET https://whatever/css1 [HTTP/1.1 304 OK 25ms]
GET https://whatever/image7 [0ms]
up and still thinks it worked fine.
Any suggestions on how to proceed further on this? Happy to provide
specific details/logs via email if required.
I’m now seeing the same issue again (static items coming from proxy
Firefox → Nginx 1.3.15 → HAproxy → Tomcat
Do you mean “return 444”?
Indeed, I accidentally confused 499 with 444 and as a result I
misunderstood the
issue. Thanks for correcting me.
i am also experiencing this problem running 1.4.2.
Hi David. The response I got from my Valentin off-list was that there
is a
known incompatibility with SPDY and proxy cache, due to the way proxy
cache
will kill the connection to prevent it sending the body response (but
before
it has had a chance to finish dealing with all the SPDY requests, I
think).
Only solution now is to either disable SPDY or proxy cache (I went with
SPDY, of course).
I wonder if a note in the documentation might be in order to say there
are
known issues.
There is supposed to be a rewrite coming for proxy cache that will help,
but
not sure when it is likely to appear.
It would be nice to get some more informations about the current status
and
work.
Since RHEL 6.5 / Centos 6.5 there is openssl 1.0.1e available for me and
I
would
like to activate SPDY on our systems.