This allows viewing the last few messages written to the SharedCircularBuffer in
NgxMessageHandler through url /ngx_pagespeed_message
Related issue: https://github.com/pagespeed/ngx_pagespeed/issues/153
Squash-merge of Otto's #180.
This adds /ngx_pagespeed_statistics. It also uses SharedMemoryStatistics instead
of the SimpleStatistics currently used, and sets them as the default. It also
adds support for tracking per server{} statistics.
Cleaning up of shared segments is disabled, because the current psol version we
link in has a problem with the ordering of nginx's events during a configuration
reload.
The referrer statistics will be ported in a separate pull.
Related to issue #133
Squash-merge of Otto's work in #176.
This adds an NgxMessageHandler, that uses ngx_log_error to output messages. It
is heavily based on apache_message_handler from mod_pagespeed.
It falls back to an internal GoogleMessageHandler if the required initialisation
has not been performed yet.
It can also install a crash handler, that will try to log a backtrace upon
receiving certain signals. In preparation of us porting /ngx_pagespeed_messages,
it also keeps the last few messages in a SharedCircularBuffer
(Squash-merge of Otto's #163)
We need to have the NgxRewriteDriverFactory available at configuration parse
time to set options on it. This change moves instantiation of the factory in
front of configuration parsing. Afterwards, a check is done to see if we where
enabled anywhere. If we where not enabled / do not have any active server
contexts, the NgxRewriteDriverFactory is deleted. It's not very elegant, but we
can't think of anything better currently.
Squash merge of Otto's #165.
This is the ngx_pagespeed half of a refactor morlovich made:
Split out the settings that can be shared between
mod_pagespeed and ngx_pagespeed into a separate class.
This is step 1 out of ??? of refactors to reduce code dupe
between mod_pagespeed and ngx_pagespeed and make some
things more testable.
(Step 2 will be to share some of the configuration parsing
code).
-- https://code.google.com/p/modpagespeed/source/detail?r=2443
A normal .pagespeed. url looks like:
256x192vPuzzle.jpg.pagespeed.ic.alA0AdlR-2.jpg
If someone turns on RunExperiment, however, we generate urls like:
256x192vPuzzle.jpg.pagespeed.a.ic.alA0AdlR-2.jpg
256x192vPuzzle.jpg.pagespeed.b.ic.alA0AdlR-2.jpg
The new section is always a single letter between a and z. We need to catch
these and pass them through to PageSpeed.
Before the experiment code was just setting the need_to_store_experiment_data
option but nothing was looking at that option. Rewrote the code, basing it on
InstawebContext::SetFuriousStateAndCookie, in order to actually set the cookie
to support the experiment. There are tests for this functionality, but we're
waiting on issue #40 to be able to run them.
Manual testing (with line wrapping):
$ curl -s -D- http://localhost:8050/mod_pagespeed_example/ | grep GFURIOUS
Set-Cookie: _GFURIOUS=1; Expires=Fri, 01 Feb 2013 21:38:31 GMT;
Domain=.localhost; Path=/
$ curl -s -D- http://localhost:8050/mod_pagespeed_example/ | grep GFURIOUS
Set-Cookie: _GFURIOUS=2; Expires=Fri, 01 Feb 2013 21:42:56 GMT;
Domain=.localhost; Path=/
And it responds properly on receiving the cookie, although it did that before
this change too.
guard against server only options being configured at location scope this
introduces a duplicated list of server-level-only options from mod_instaweb.cc,
which is a short term solution and should be removed later on
Fixes#99.
Shut down the driver factory before the proxy fetch factory.
shutting down the driver factory will make sure that all worker
threads are stopped, This prevents in-flight callbacks to
destroyed proxy fetch factories, so we should be able to safely
delete them
This fixes#109.