The primary motivation of this change was to allow third-party modules
to be used with OpenResty, but it also results in a significant
reduction of code duplication.
This is what I've suspected a while ago[1]:
> Heads-up everyone: After testing this in a few production instances,
> it seems that some browsers still get cache hits for new store paths
> (and changed contents) for some reason. I highly suspect that it might
> be due to the last-modified header (as mentioned in [2]).
>
> Going to test this with last-modified disabled for a little while and
> if this is the case I think we should improve that patch by disabling
> last-modified if serving from a store path.
Much earlier[2] when I reviewed the patch, I wrote this:
> Other than that, it looks good to me.
>
> However, I'm not sure what we should do with Last-Modified header.
> From RFC 2616, section 13.3.4:
>
> - If both an entity tag and a Last-Modified value have been
> provided by the origin server, SHOULD use both validators in
> cache-conditional requests. This allows both HTTP/1.0 and
> HTTP/1.1 caches to respond appropriately.
>
> I'm a bit nervous about the SHOULD here, as user agents in the wild
> could possibly just use Last-Modified and use the cached content
> instead.
Unfortunately, I didn't pursue this any further back then because
@pbogdan noted[3] the following:
> Hmm, could they (assuming they are conforming):
>
> * If an entity tag has been provided by the origin server, MUST
> use that entity tag in any cache-conditional request (using If-
> Match or If-None-Match).
Since running with this patch in some deployments, I found that both
Firefox and Chrome/Chromium do NOT re-validate against the ETag if the
Last-Modified header is still the same.
So I wrote a small NixOS VM test with Geckodriver to have a test case
which is closer to the real world and I indeed was able to reproduce
this.
Whether this is actually a bug in Chrome or Firefox is an entirely
different issue and even IF it is the fault of the browsers and it is
fixed at some point, we'd still need to handle this for older browser
versions.
Apart from clearing the header, I also recreated the patch by using a
plain "git diff" with a small description on top. This should make it
easier for future authors to work on that patch.
[1]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-495072764
[2]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-451644084
[3]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-451646135
Signed-off-by: aszlig <aszlig@nix.build>
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
So far, the Nix store directory was hardcoded and if someone uses a
different Nix store directory the patch won't work. Of course, this is
pretty uncommon, but by not only substituting the store directory but
also the length of it we also save a few calls to ngx_strlen(), which
should save us a few cycles.
Signed-off-by: aszlig <aszlig@nix.build>
The original patch introduced a new "real" variable which gets populated
(and allocated) via ngx_realpath(). It's properly freed in error
conditions but it won't be freed if ngx_http_set_etag returns
successfully.
Adding another ngx_free() just before returning fixes that memory leak.
I also fixed a small indentation issue along the way.
Signed-off-by: aszlig <aszlig@nix.build>
This adds the nginx module `ngx_http_proxy_connect_module` which allows
to tunnel HTTPS through an nginx proxy[1].
As this module contained patches for several nginx version, some minor
adjustments were needed:
* Allowed each entry in `nginxModules` to provide patches.
* Added an optional `supports` attribute to ensure that each module can
determine if it supports the currently built nginx version (e.g. stable
1.14 ATM or mainline 1.15 ATM).
[1] https://github.com/chobits/ngx_http_proxy_connect_module
Currently, it seems there is no easy way to override package to add
modules. For example, if we want to add the `ipscrub` module, we can
do:
pkgs.nginxStable.override {
modules = [ pkgs.nginxModules.ipscrub ];
};
But, then, we loose `rtmp`, `dav` and `moreheaders` which are defined
in `all-packages.nix`. With this modification, we can now do:
pkgs.nginxStable.override {
modules = pkg.nginxStable.passthru.modules ++ [ pkgs.nginxModules.ipscrub ];
};
