What is the difference bewteen nginx against mp4 modules

Hi What is the difference between the mp4 module and the slice module for streaming mp4 videos in nginx? Both seem to work on streaming mp4 files but I can't really see the difference. On another aspect, the slice module seems to work nicely with the caching. Where slices from cache module are

Re: How to redirect to https when using load balancer in front of nginx

In order to redirect http to https, you have to define a listener rule in the ALB that redirects all traffic on port 80 to port 443 (of the ALB) with the original path and query parameters. The status code should be a 301 (permanent redirection). That's the context between the client and the ALB.

Re: Errors suggesting nginx isn't started as root

This is still a big mystery to me. Upgrading to nginx 1.16.1 didn’t help. As far as I can understand, the nginx master process IS running with root privileges. > On 19 Sep 2018, at 2.00, Palvelin Postmaster via nginx > wrote: > > Why am I getting these log warn/emerg? Running Nginx 1.14.0

How to redirect to https when using load balancer in front of nginx

I have AWS ALB in front of an instance running nginx. I want to terminate https at the load balancer. I have setup ALB's http listener to redirect http to https and forward https to the instance’s port 80. I’m switching from using apache to nginx. My apache currently responds on a single port

How to redirect to https when using load balancer in front of nginx

I have AWS ALB in front of an instance running nginx. I want to terminate https at the load balancer. I have setup ALB's http listener to redirect http to https and forward https to the instance’s port 80. I’m switching from using apache2 to nginx. My apache responds on a single port 80. In

Re: Allow internal redirect to URI x, but deny external request for x?

On 09/04, Jürgen Wagner (DVT) wrote: > This is the effect you get by having the HTTP equivalent of a symbolic link > in the NGINX (visible to the browser), not in the file system (which is > opaque to users). The file system link will (over time) serve different > contents under the same URL, so

Re: [PATCH] Core: monitoring anonymous map on Darwin platform

Well it highlight them a little bit more, easier to parse, easier to identify in case with plethora of third party modules. Regards. On Wed, 4 Sep 2019 at 16:01, Maxim Dounin wrote: > > Hello! > > On Fri, Aug 23, 2019 at 06:00:29AM +0100, David Carlier wrote: > > > # HG changeset patch > > #

Re: [PATCH] Core: monitoring anonymous map on Darwin platform

Hello! On Fri, Aug 23, 2019 at 06:00:29AM +0100, David Carlier wrote: > # HG changeset patch > # User David Carlier > # Date 1566493379 -3600 > # Thu Aug 22 18:02:59 2019 +0100 > # Node ID adc68231e590554860b11ee851b293e46ba652db > # Parent 9f1f9d6e056a4f85907957ef263f78a426ae4f9c > Core:

Re: Allow internal redirect to URI x, but deny external request for x?

Hi Lewis,   no, that won't cause double requests. /myapp/current/blah.html 307 => /myapp/releases/1.2.0/blah.html and from thereon (as we did not redirect internally, but rather externally), any further accesses will happen unter the true "releases" path (ideally, as relative URLs).

Re: Allow internal redirect to URI x, but deny external request for x?

On 09/04, Jürgen Wagner (DVT) wrote: > Now, you want to be able to say what is the "current" version and reflect > this in the URL namespace as well. In the file system, that's a symbolic > link. In the URL namespace of NGINX, that could be a redirection (status > code 307). Both approaches would

Re: Needing TLS handshake to fail

Hello! On Wed, Sep 04, 2019 at 09:25:57AM -0400, Phillip Odam wrote: [...] > Also, the following reference was provided providing a basis for the TLS > handshake requirement, sections 7.2.1 and 7.2.2 - > https://tools.ietf.org/html/rfc5246#section-7.2.1. Admittedly production >

Re: Needing TLS handshake to fail

Hi Maxim Thanks for the prompt feedback. My understanding for requiring the TLS itself to fail, as opposed to doing exactly what you described which is also exactly what we've done for other endponts... I quite like nginx's ability here, is that it prevents being able to take advantage of

Re: Needing TLS handshake to fail

Hello! On Wed, Sep 04, 2019 at 08:35:05AM -0400, Phillip Odam wrote: > Hi, > > I tried asking the following on the general mailing list but I'm > guessing this is tending more towards development. > > I have a project that involves mutual / two way TLS and one of the > requirements is that

Needing TLS handshake to fail

Hi, I tried asking the following on the general mailing list but I'm guessing this is tending more towards development. I have a project that involves mutual / two way TLS and one of the requirements is that the TLS handshake must fail ie. be terminated before completion if the handshake is

Re: [PATCH] HTTP: added the preserve_method option to the error_page directive.

Hello! On Tue, Sep 03, 2019 at 12:07:53PM -0700, Thibault Charbonnier wrote: > # HG changeset patch > # User Thibault Charbonnier > # Date 1567537546 25200 > # Tue Sep 03 12:05:46 2019 -0700 > # Node ID 68ba3d36bff4213e3fedc538021e8cbece85e508 > # Parent

[nginx] Fixed "return" with discarding invalid chunked body.

details: https://hg.nginx.org/nginx/rev/a7e8f953408e branches: changeset: 7563:a7e8f953408e user: Sergey Kandaurov date: Wed Sep 04 13:33:51 2019 +0300 description: Fixed "return" with discarding invalid chunked body. When ngx_http_discard_request_body() call was added to

Re: NGINX R19 Javascript bug with keyval maps

Hello. On 04/09/2019 06:20, j94305 wrote: > A little correction to my earlier message: IPv6 addresses also seem to work. > In my test, I was checking for a dot in the key, and that excluded IPv6 > addresses. > > However, CIDR ranges still fail. > Please approach nginx-plus support with this