From jeads442 at gmail.com  Sat Sep  1 16:35:54 2018
From: jeads442 at gmail.com (Jason Eads)
Date: Sat, 1 Sep 2018 11:35:54 -0500
Subject: WSGI gets no QUERY_STRING
In-Reply-To: <CAE0_0Ux9ATUQFttZ_Y3knMezijosiDm9Q2TAt9_5zqP1U2WFQA@mail.gmail.com>
References: <CAE0_0Ux9ATUQFttZ_Y3knMezijosiDm9Q2TAt9_5zqP1U2WFQA@mail.gmail.com>
Message-ID: <CAE0_0Uwns5SAnqifp3Hrri5Oy8CoCtr2Pm2JV9owDZrM8__ELQ@mail.gmail.com>

It appears that this issue was not a problem with nginx unit.

After wasting a lot of time with the very misleading Q&A thread
https://stackoverflow.com/questions/8130692/how-can-query-string-parameters-be-forwarded-through-a-proxy-pass-with-nginx
I determined that no unusual nginx configuration change was necessary to
pass the parameters via proxy_pass.

The shell was trimming anything following an '&' character unless the url
was surrounded with quotation marks.
For example:
curl "127.0.0.1:8888?v1=1&v2=2 <http://127.0.0.1:8888/?v1=1&v2=2>"

There was a bug in my detection code that failed to recognize when the
issue had been fixed.

On Thu, Aug 30, 2018 at 3:33 AM Jason Eads <jeads442 at gmail.com> wrote:

> I'm using nginx unit. I'm attempting to pass a query string to a python
> script that unit is hosting via curl as a test. A hello_world.py example
> works fine, implying unit configuration is not the issue. Example URLs
> listed below. My code is receiving an empty string for
> environ.QUERY_STRING in every case. What is the appropriate procedure or
> URL format to pass arguments into a wsgi python script via nginx unit?
>
> My tests showed that with module set no additional path needed to be
> provided. The IP address and port was enough to run hello_world.py.
>
> VARIATIONS:
> curl 127.0.0.1:8888?v1=1&v2=2
> curl 127.0.0.1:8888/?v1=1&v2=2
> curl 127.0.0.1:8888/index?v1=1&v2=2
> curl 127.0.0.1:8888/index.py?v1=1&v2=2
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/unit/attachments/20180901/e0e65e14/attachment.html>

From vbart at nginx.com  Fri Sep 21 14:03:03 2018
From: vbart at nginx.com (Valentin V. Bartenev)
Date: Fri, 21 Sep 2018 17:03:03 +0300
Subject: Unit 1.4 release
Message-ID: <6253570.AWjRV4pjsW@vbart-workstation>

Hello,

I'm glad to announce a new release of NGINX Unit.

The key feature of the new version is dynamically configurable TLS support
with certificate storage API that provides detailed information about your
certificate chains, including common and alternative names as well as
expiration dates.

See the documentation for details:

 - https://unit.nginx.org/configuration/#ssl-tls-and-certificates

This is just our first step in TLS support.  More configuration options
and various TLS-related features will be added in the future.

Full-featured HTTP/2 support is also in our sights.


Changes with Unit 1.4                                            20 Sep 2018

    *) Change: the control API maps the configuration object only at
       "/config/".

    *) Feature: TLS support for client connections.

    *) Feature: TLS certificates storage control API.

    *) Feature: Unit library (libunit) to streamline language module
       integration.

    *) Feature: "408 Request Timeout" responses while closing HTTP
       keep-alive connections.

    *) Feature: improvements in OpenBSD support. Thanks to David Carlier.

    *) Bugfix: a segmentation fault might have occurred after
       reconfiguration.

    *) Bugfix: building on systems with non-default locale might be broken.

    *) Bugfix: "header_read_timeout" might not work properly.

    *) Bugfix: header fields values with non-ASCII bytes might be handled
       incorrectly in Python 3 module.


In a few weeks, we are going to add preliminary Node.js support.  It's almost
ready; our QA engineers are already testing it.

Now we are also working on Java module, WebSockets support, flexible request
routing, and serving of static media assets.

Please also welcome Artem Konev, who joined our team as a technical writer.
He has already started improving documentation on the website and updated
it with the configuration options currently available:

 - https://hg.nginx.org/unit-docs/

Of course, the website still leaves much to be desired, so Artem will strive
to provide industry-grade documentation for Unit.  You are welcome to join
this effort with your ideas, suggestions, and edits: just send a pull request
or open an issue in our documentation repository on GitHub:

 - https://github.com/nginx/unit-docs/


Stay tuned!

  wbr, Valentin V. Bartenev