As of r3447 ServerContext::ChildInit is now in system/, which means we can
delete a lot of code.
DangerFetchFromUnknownHosts and FetchWithGzip are now handled by RewriteOptions.
ServerContext now needs a hostname and port, but we don't have one so we
hackishly provide a different unique id.
Adjust for fetchers and options that moved from apache/ to system/ in r3390.
Use AllocateFetcher() hook from r3402 to put the native fetcher into the fetcher
map maintained by the SystemRewriteDriverFactory.
SystemRewriteDriverFactory was expanded by r3366 to do a lot of what
NgxRewriteDriverFactory used to have to do. Take advantage of this and
simplifiy our code.
Squash-merge of chaizhenhua's work over many pull requests, especially #450.
The copy of in_place_resource_recorder.cc is temporary and can be removed after
the next PSOL release.
Fixes to allow ngx_pagespeed trunk-tracking branch to compile and work with r3298 mod_pagespeed revision:
- Config fix to include path for critical_keys.pb.h.
- Make changes needed due to RewriteOptions refactoring done in https://code.google.com/p/modpagespeed/source/detail?r=3226
sligocki is adding a feature to pagespeed where it will parse your statistics
for you and determine if there are any problems. This CL wires up the
ConsoleHandler and also includes a few required files in the build process.
It doesn't work yet, because as of svn r3193 the console has a hardcoded json
request to '/mod_pagespeed_statistics' and in nginx we use '/ngx_...' .
I've tested this by changing all uses here to use the "mod_..." version and that
worked, but I've undone those changes.
Make us live in peace with nginx's SSI module:
- Moved our module so that we we see the content that the ssi module produces as
a whole. (right before the gzip module does its work).
- Made the header and content filters bail out for subrequests, so we don't
attempt to rewrite the sub requests that the ssi module fires.
- Changed NGX_HTTP_SSI_BUFFERED to use an unused flag, so I could rule out that
the SSI module got confused by ngx_pagespeed manipulating that flag as well.
- Handled the case in ps_update() where CollectAccumulatedWrites gives us a null
cl
Squash-merge of Otto's #242.
Makes sure we use the LoopbackRouteFetcher, and also wires up AddHeadersFetcher.
Note that this pulls in loopback_route_fetcher.cc from svn revision r2649
The LoopbackRouteFetcher is applied unconditionally, while in mod_pagespeed it
is not applied when one of these configuration settings is true:
* disable_loopback_routing
* slurping_enabled, or
* test_proxy is set
I added a TODO for that.
(Sqash-merge of Otto's #193.)
This wires up cleanup code shared memory segments.
It uses slightly modified copies of pthread_shared_mem.cc/h, containing a change
proposal to support our ordering of events during a configuration reload.
It can be tested and reviewed through this branch.
I did some extensive tests, it seems segment cleanup is not perfect yet
(segments for named locks, per vhost statistics segments). I think we need to
fix that in the trunk-tracking branch or in a separate pull though. It seems the
current trunk of psol has improvements that may fix this, and fixing it in this
pull will make it larger and more complex then I would like it to be.
Squash-merge of Otto's #179.
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 want people to be able to install ngx_pagespeed like any other nginx module.
If PSOL were a full-fledged library with a stable interface we could simply say
"install PSOL" which might be as easy as `apt-get install psol-dev`, but it's
not. Instead we directly include a precompiled binary library along with its
headers. By building the binaries on something sufficiently old (Centos 5.4)
they should work pretty much everywhere someone might think to run
ngx_pagespeed, but building from source is still a documented option if they
don't.
Headers and binaries are from trunk of r2338, as documented in the READMEs.
Jeff Kaufman