After calling ngx_http_filter_finalize_request return NGX_DONE
as we are still in pre-access phase. This bug shows up when the
"special" response is generated from, for example, php as opposed
to a static file.
Second part of the fix for
https://github.com/pagespeed/ngx_pagespeed/issues/1146
This change makes ngx_pagespeed listen to the FollowFlushes option.
When set to on (=default), ngx_pagespeed will forward incoming flushes
to ProxyFetch. When writing output, we'll now also set the flush flag on
the buffers we are about to send downstream.
Companion to mps commit: https://github.com/pagespeed/mod_pagespeed/commit/02de03e825bbd1f8d4ad4e1a1bef5263a16f3857
When there is no top-level configuration but only server configuration,
we don't have main options to set and consider. This prevents
a NULL dereference in that case. (Later on we'll writes out a message
about why we cannot startup with this configuration).
The renaming is to make it clear that kProcessScopeStrict (aka what
ngx_pagespeed does for everything already) is what new code should be
using, rather than current kProcessScope/upcoming kLegacyProcessScope
which does weird backwards compatible things in mod_pagespeed.
This change makes nginx close the request when we receive a close
event or RST_STREAM while waiting for an async PSOL op to complete
by setting a read event handler, as inspired by the limit request
module from nginx.
Should fix https://github.com/pagespeed/ngx_pagespeed/issues/1146
The report from some time ago mentioned three Vary: headers,
but I can now only reproduce two using trunk-tracking plus the
original repro-configuration.
This fix unflags r->gzip_vary as set by the gzip module when PSOL
hands us Vary: Accept-Encoding, to make sure that nginx's core
header filter doesn't append another one.
Fixes https://github.com/pagespeed/ngx_pagespeed/issues/1064
- Fix nginx-side flow so we handle .pagespeed. resources ok
when they will land on a customized 404 internal location.
- Additionally, check for a wiped request context and make sure
we do not dereference a null pointer, which is what hurt in
the flow we entered above as the IPRO lookup still was
generating events while the nginx side request context was
gone.
- Also, as a preliminary measure, do not check fail when we
receive a stale event originating from a NgxBaseFetch that
is no longer associated with our request context.
Do log a warning so we'll hear about this happening either
through system test failures or a bug report.
Fixes https://github.com/pagespeed/ngx_pagespeed/issues/1081
@rfnx fixed#957 in acb89a, but this was accidentally merged to master
instead of trunk-tracking. I checked for this sort of problem as part
of the 1.10 release, but missed this commit. Restored.
Fixes#1054
It turns out to be possible to initialize logging earlier by
grabbing the log from a global ngx_cycle structure.
This makes us start logging earlier, yet loses the
"No threading detected ..." messages both from stderr and
in error.log when nginx initially starts.
With this change, these messages will now be logged as we start
logging earlier:
"
flush
.
"
These originate from SystemCachePath::CacheKey which appends
newlines to the key, and the resulting cache key ends up being
logged. We might want to change that, because the resulting
lines in error.log look weird and might raise questions.
Fixes https://github.com/pagespeed/ngx_pagespeed/issues/895
Add compiler version checks for what we want to support going forward.
Also make us actually build with clang (the log_message_handler.cc change
and config.make change)
When configuring downstream caching if you have an origin with multiple caches in front of it you might want to choose how you handle requests in response to which cache you're getting them from. Whitelist DownstreamCachePurgeLocationPrefix, DownstreamCachePurgeMethod, and DownstreamCacheRewrittenPercentageThreshold for scripting so this is possible.
Jeff Kaufman