[api][sdk][dev][oslo] using uWSGI breaks CORS config
Fellow Devs,
as you might have noticed I started taking care of openstack/js-openstack-lib, now under the openstacksdk umbrella [1]. First goal is to modernize the CI to use Zuul v3, current devstack and nodejs, still WIP [2].
As part of the original suite of tests, the unit and functional tests are run from browsers as well as from node. And, as you may know, browsers care about CORS [3]. js-openstack-lib is connecting to various OpenStack APIs (currently limited to keystone, glance, neutron and nova) to act on behalf of the user (just like openstacksdk/client does). oslo.middleware, as used by those APIs, provides a way to configure CORS by setting params in the [cors] group but uWSGI seemingly ignores that completely [4]. I had to switch to mod_wsgi+apache instead of uwsgi+apache to get past that issue. I could not reproduce locally because kolla (thankfully) uses mostly mod_wsgi atm.
The issue I see is that uWSGI is proposed as the future and mod_wsgi is termed deprecated. However, this means the future is broken w.r.t. CORS and so any modern web interface with it if not sitting on the exact same host and port (which is usually different between OpenStack APIs and any UI).
[1] https://review.opendev.org/701854 [2] https://review.opendev.org/702132 [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS [4] https://github.com/unbit/uwsgi/issues/1550
-yoctozepto
hi Radoslaw,
i am also curious about this because i had thought we had CORS issued solved for uWSGI in the past, i will need to look around to find the conversations i was having.
thanks for sharing your investigation, i think this is interesting.
peace o/
On Fri, Jan 17, 2020 at 1:45 PM Radosław Piliszek < radoslaw.piliszek@gmail.com> wrote:
Fellow Devs,
as you might have noticed I started taking care of openstack/js-openstack-lib, now under the openstacksdk umbrella [1]. First goal is to modernize the CI to use Zuul v3, current devstack and nodejs, still WIP [2].
As part of the original suite of tests, the unit and functional tests are run from browsers as well as from node. And, as you may know, browsers care about CORS [3]. js-openstack-lib is connecting to various OpenStack APIs (currently limited to keystone, glance, neutron and nova) to act on behalf of the user (just like openstacksdk/client does). oslo.middleware, as used by those APIs, provides a way to configure CORS by setting params in the [cors] group but uWSGI seemingly ignores that completely [4]. I had to switch to mod_wsgi+apache instead of uwsgi+apache to get past that issue. I could not reproduce locally because kolla (thankfully) uses mostly mod_wsgi atm.
The issue I see is that uWSGI is proposed as the future and mod_wsgi is termed deprecated. However, this means the future is broken w.r.t. CORS and so any modern web interface with it if not sitting on the exact same host and port (which is usually different between OpenStack APIs and any UI).
[1] https://review.opendev.org/701854 [2] https://review.opendev.org/702132 [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS [4] https://github.com/unbit/uwsgi/issues/1550
-yoctozepto
Hi, Michael!
Thanks for your interest. I was also surprised that it does not work. It looks simple enough to not break...
Since I wrote the email, I did more research on how to tackle this problem. For now I posted a bug to devstack that CORS is out of reach with pure devstack [1]. Only keystone and placement can be configured to use mod_wsgi, others default to uwsgi (or eventlet, to be precise, but these are irrelevant). It's really either hacking browsers or hacking apache config to include relevant CORS headers.
[1] https://bugs.launchpad.net/devstack/+bug/1860287
-yoctozepto
wt., 21 sty 2020 o 10:00 Michael McCune elmiko@redhat.com napisał(a):
hi Radoslaw,
i am also curious about this because i had thought we had CORS issued solved for uWSGI in the past, i will need to look around to find the conversations i was having.
thanks for sharing your investigation, i think this is interesting.
peace o/
On Fri, Jan 17, 2020 at 1:45 PM Radosław Piliszek radoslaw.piliszek@gmail.com wrote:
Fellow Devs,
as you might have noticed I started taking care of openstack/js-openstack-lib, now under the openstacksdk umbrella [1]. First goal is to modernize the CI to use Zuul v3, current devstack and nodejs, still WIP [2].
As part of the original suite of tests, the unit and functional tests are run from browsers as well as from node. And, as you may know, browsers care about CORS [3]. js-openstack-lib is connecting to various OpenStack APIs (currently limited to keystone, glance, neutron and nova) to act on behalf of the user (just like openstacksdk/client does). oslo.middleware, as used by those APIs, provides a way to configure CORS by setting params in the [cors] group but uWSGI seemingly ignores that completely [4]. I had to switch to mod_wsgi+apache instead of uwsgi+apache to get past that issue. I could not reproduce locally because kolla (thankfully) uses mostly mod_wsgi atm.
The issue I see is that uWSGI is proposed as the future and mod_wsgi is termed deprecated. However, this means the future is broken w.r.t. CORS and so any modern web interface with it if not sitting on the exact same host and port (which is usually different between OpenStack APIs and any UI).
[1] https://review.opendev.org/701854 [2] https://review.opendev.org/702132 [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS [4] https://github.com/unbit/uwsgi/issues/1550
-yoctozepto
On Tue, Jan 21, 2020 at 5:37 AM Radosław Piliszek < radoslaw.piliszek@gmail.com> wrote:
Hi, Michael!
Thanks for your interest. I was also surprised that it does not work. It looks simple enough to not break...
Since I wrote the email, I did more research on how to tackle this problem. For now I posted a bug to devstack that CORS is out of reach with pure devstack [1].
that sounds like a good first step.
Only keystone and placement can be configured to use mod_wsgi, others
default to uwsgi (or eventlet, to be precise, but these are irrelevant). It's really either hacking browsers or hacking apache config to include relevant CORS headers.
this is something that i think we need to know though, because if uWSGI has broken CORS support then we need to fix it or start advising against its usage.
peace o/
[1] https://bugs.launchpad.net/devstack/+bug/1860287
-yoctozepto
wt., 21 sty 2020 o 10:00 Michael McCune elmiko@redhat.com napisał(a):
hi Radoslaw,
i am also curious about this because i had thought we had CORS issued
solved for uWSGI in the past, i will need to look around to find the conversations i was having.
thanks for sharing your investigation, i think this is interesting.
peace o/
On Fri, Jan 17, 2020 at 1:45 PM Radosław Piliszek <
radoslaw.piliszek@gmail.com> wrote:
Fellow Devs,
as you might have noticed I started taking care of
openstack/js-openstack-lib,
now under the openstacksdk umbrella [1]. First goal is to modernize the CI to use Zuul v3, current devstack and nodejs, still WIP [2].
As part of the original suite of tests, the unit and functional tests are run from browsers as well as from node. And, as you may know, browsers care about CORS [3]. js-openstack-lib is connecting to various OpenStack APIs (currently limited to keystone, glance, neutron and nova) to act on behalf of the user (just like openstacksdk/client does). oslo.middleware, as used by those APIs, provides a way to configure CORS by setting params in the [cors] group but uWSGI seemingly ignores that completely [4]. I had to switch to mod_wsgi+apache instead of uwsgi+apache to get past that issue. I could not reproduce locally because kolla (thankfully) uses mostly mod_wsgi atm.
The issue I see is that uWSGI is proposed as the future and mod_wsgi is termed deprecated. However, this means the future is broken w.r.t. CORS and so any modern web interface with it if not sitting on the exact same host and port (which is usually different between OpenStack APIs and any UI).
[1] https://review.opendev.org/701854 [2] https://review.opendev.org/702132 [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS [4] https://github.com/unbit/uwsgi/issues/1550
-yoctozepto
On 1/21/20 4:55 PM, Michael McCune wrote:
On Tue, Jan 21, 2020 at 5:37 AM Radosław Piliszek <radoslaw.piliszek@gmail.com mailto:radoslaw.piliszek@gmail.com> wrote:
Hi, Michael! Thanks for your interest. I was also surprised that it does not work. It looks simple enough to not break... Since I wrote the email, I did more research on how to tackle this problem. For now I posted a bug to devstack that CORS is out of reach with pure devstack [1].that sounds like a good first step.
Only keystone and placement can be configured to use mod_wsgi, others default to uwsgi (or eventlet, to be precise, but these are irrelevant). It's really either hacking browsers or hacking apache config to include relevant CORS headers.this is something that i think we need to know though, because if uWSGI has broken CORS support then we need to fix it or start advising against its usage.
Just to clarify, based on [0] it looks like this is a uwsgi bug and not something we're doing wrong (other than recommending uwsgi ;-). Is that correct?
0: https://github.com/unbit/uwsgi/issues/1550
peace o/
[1] https://bugs.launchpad.net/devstack/+bug/1860287 -yoctozepto wt., 21 sty 2020 o 10:00 Michael McCune <elmiko@redhat.com <mailto:elmiko@redhat.com>> napisał(a): > > hi Radoslaw, > > i am also curious about this because i had thought we had CORS issued solved for uWSGI in the past, i will need to look around to find the conversations i was having. > > thanks for sharing your investigation, i think this is interesting. > > peace o/ > > On Fri, Jan 17, 2020 at 1:45 PM Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>> wrote: >> >> Fellow Devs, >> >> as you might have noticed I started taking care of openstack/js-openstack-lib, >> now under the openstacksdk umbrella [1]. >> First goal is to modernize the CI to use Zuul v3, current devstack and >> nodejs, still WIP [2]. >> >> As part of the original suite of tests, the unit and functional tests >> are run from browsers as well as from node. >> And, as you may know, browsers care about CORS [3]. >> js-openstack-lib is connecting to various OpenStack APIs (currently >> limited to keystone, glance, neutron and nova) to act on behalf of the >> user (just like openstacksdk/client does). >> oslo.middleware, as used by those APIs, provides a way to configure >> CORS by setting params in the [cors] group but uWSGI seemingly ignores >> that completely [4]. >> I had to switch to mod_wsgi+apache instead of uwsgi+apache to get past >> that issue. >> I could not reproduce locally because kolla (thankfully) uses mostly >> mod_wsgi atm. >> >> The issue I see is that uWSGI is proposed as the future and mod_wsgi >> is termed deprecated. >> However, this means the future is broken w.r.t. CORS and so any modern >> web interface with it if not sitting on the exact same host and port >> (which is usually different between OpenStack APIs and any UI). >> >> [1] https://review.opendev.org/701854 >> [2] https://review.opendev.org/702132 >> [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS >> [4] https://github.com/unbit/uwsgi/issues/1550 >> >> -yoctozepto >>
On Tue, 2020-01-21 at 17:30 +0100, Ben Nemec wrote:
On 1/21/20 4:55 PM, Michael McCune wrote:
On Tue, Jan 21, 2020 at 5:37 AM Radosław Piliszek <radoslaw.piliszek@gmail.com mailto:radoslaw.piliszek@gmail.com> wrote:
Hi, Michael! Thanks for your interest. I was also surprised that it does not work. It looks simple enough to not break... Since I wrote the email, I did more research on how to tackle this problem. For now I posted a bug to devstack that CORS is out of reach with pure devstack [1].that sounds like a good first step.
Only keystone and placement can be configured to use mod_wsgi, others default to uwsgi (or eventlet, to be precise, but these are irrelevant). It's really either hacking browsers or hacking apache config to include relevant CORS headers.this is something that i think we need to know though, because if uWSGI has broken CORS support then we need to fix it or start advising against its usage.
Just to clarify, based on [0] it looks like this is a uwsgi bug and not something we're doing wrong (other than recommending uwsgi ;-). Is that correct?
is it somehting that we expect the wsgi server to add or the applciation? e.g. should the CORS headders be added by the apache/nginx/uwsgi or openstack.
but my only interaction in the past was setting it via the apache .htaccess file. https://enable-cors.org/server_apache.html you can also do it in nginx https://enable-cors.org/server_nginx.html
it seam like we use oslo midelware to do this dynmaically form the api code.
https://docs.openstack.org/oslo.middleware/latest/admin/cross-project-cors.h... so perhaps that is not executing or uswsgi si stripping the headers.
they may be filtering them but i cant really find any documentaiton on uswgi and CORS configuration
peace o/
[1] https://bugs.launchpad.net/devstack/+bug/1860287 -yoctozepto wt., 21 sty 2020 o 10:00 Michael McCune <elmiko@redhat.com <mailto:elmiko@redhat.com>> napisał(a): > > hi Radoslaw, > > i am also curious about this because i had thought we had CORS issued solved for uWSGI in the past, i will need to look around to find the conversations i was having. > > thanks for sharing your investigation, i think this is interesting. > > peace o/ > > On Fri, Jan 17, 2020 at 1:45 PM Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>> wrote: >> >> Fellow Devs, >> >> as you might have noticed I started taking care of openstack/js-openstack-lib, >> now under the openstacksdk umbrella [1]. >> First goal is to modernize the CI to use Zuul v3, current devstack and >> nodejs, still WIP [2]. >> >> As part of the original suite of tests, the unit and functional tests >> are run from browsers as well as from node. >> And, as you may know, browsers care about CORS [3]. >> js-openstack-lib is connecting to various OpenStack APIs (currently >> limited to keystone, glance, neutron and nova) to act on behalf of the >> user (just like openstacksdk/client does). >> oslo.middleware, as used by those APIs, provides a way to configure >> CORS by setting params in the [cors] group but uWSGI seemingly ignores >> that completely [4]. >> I had to switch to mod_wsgi+apache instead of uwsgi+apache to get past >> that issue. >> I could not reproduce locally because kolla (thankfully) uses mostly >> mod_wsgi atm. >> >> The issue I see is that uWSGI is proposed as the future and mod_wsgi >> is termed deprecated. >> However, this means the future is broken w.r.t. CORS and so any modern >> web interface with it if not sitting on the exact same host and port >> (which is usually different between OpenStack APIs and any UI). >> >> [1] https://review.opendev.org/701854 >> [2] https://review.opendev.org/702132 >> [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS >> [4] https://github.com/unbit/uwsgi/issues/1550 >> >> -yoctozepto >>
Ben wrote:
it looks like this is a uwsgi bug and not something we're doing wrong (other than recommending uwsgi ;-).
Precisely. Well, there is always a chance either side does something wrong until one acknowledges doing it wrong but if django and oslo.middleware can send CORS headers via mod_wsgi and both cannot via uWSGI, then it's uWSGI that's more suspicious. ;-)
Sean wrote:
is it somehting that we expect the wsgi server to add or the applciation? it seam like we use oslo midelware to do this dynmaically form the api code.
Wearing my web developer hat, I would say it's up to the application to do, in general, since different resources may need different CORS headers. In the contrived example of testing in CI, allowing anything for the sake of easy access, it does not really matter. :-)
Sean wrote:
but my only interaction in the past was setting it via the apache .htaccess file.
Yeah, any decent web server allows to add/remove/override headers.
Sean wrote:
they may be filtering them but i cant really find any documentaiton on uswgi and CORS configuration
Indeed that's what the linked bug report suggests as well as random googlable info. I wonder why nobody from uWSGI answered the bug call. :/
-yoctozepto
wt., 21 sty 2020 o 18:15 Sean Mooney smooney@redhat.com napisał(a):
On Tue, 2020-01-21 at 17:30 +0100, Ben Nemec wrote:
On 1/21/20 4:55 PM, Michael McCune wrote:
On Tue, Jan 21, 2020 at 5:37 AM Radosław Piliszek <radoslaw.piliszek@gmail.com mailto:radoslaw.piliszek@gmail.com> wrote:
Hi, Michael! Thanks for your interest. I was also surprised that it does not work. It looks simple enough to not break... Since I wrote the email, I did more research on how to tackle this problem. For now I posted a bug to devstack that CORS is out of reach with pure devstack [1].that sounds like a good first step.
Only keystone and placement can be configured to use mod_wsgi, others default to uwsgi (or eventlet, to be precise, but these are irrelevant). It's really either hacking browsers or hacking apache config to include relevant CORS headers.this is something that i think we need to know though, because if uWSGI has broken CORS support then we need to fix it or start advising against its usage.
Just to clarify, based on [0] it looks like this is a uwsgi bug and not something we're doing wrong (other than recommending uwsgi ;-). Is that correct?
is it somehting that we expect the wsgi server to add or the applciation? e.g. should the CORS headders be added by the apache/nginx/uwsgi or openstack.
but my only interaction in the past was setting it via the apache .htaccess file. https://enable-cors.org/server_apache.html you can also do it in nginx https://enable-cors.org/server_nginx.html
it seam like we use oslo midelware to do this dynmaically form the api code.
https://docs.openstack.org/oslo.middleware/latest/admin/cross-project-cors.h... so perhaps that is not executing or uswsgi si stripping the headers.
they may be filtering them but i cant really find any documentaiton on uswgi and CORS configuration
peace o/
[1] https://bugs.launchpad.net/devstack/+bug/1860287 -yoctozepto wt., 21 sty 2020 o 10:00 Michael McCune <elmiko@redhat.com <mailto:elmiko@redhat.com>> napisał(a): > > hi Radoslaw, > > i am also curious about this because i had thought we had CORS issued solved for uWSGI in the past, i will need to look around to find the conversations i was having. > > thanks for sharing your investigation, i think this is interesting. > > peace o/ > > On Fri, Jan 17, 2020 at 1:45 PM Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>> wrote: >> >> Fellow Devs, >> >> as you might have noticed I started taking care of openstack/js-openstack-lib, >> now under the openstacksdk umbrella [1]. >> First goal is to modernize the CI to use Zuul v3, current devstack and >> nodejs, still WIP [2]. >> >> As part of the original suite of tests, the unit and functional tests >> are run from browsers as well as from node. >> And, as you may know, browsers care about CORS [3]. >> js-openstack-lib is connecting to various OpenStack APIs (currently >> limited to keystone, glance, neutron and nova) to act on behalf of the >> user (just like openstacksdk/client does). >> oslo.middleware, as used by those APIs, provides a way to configure >> CORS by setting params in the [cors] group but uWSGI seemingly ignores >> that completely [4]. >> I had to switch to mod_wsgi+apache instead of uwsgi+apache to get past >> that issue. >> I could not reproduce locally because kolla (thankfully) uses mostly >> mod_wsgi atm. >> >> The issue I see is that uWSGI is proposed as the future and mod_wsgi >> is termed deprecated. >> However, this means the future is broken w.r.t. CORS and so any modern >> web interface with it if not sitting on the exact same host and port >> (which is usually different between OpenStack APIs and any UI). >> >> [1] https://review.opendev.org/701854 >> [2] https://review.opendev.org/702132 >> [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS >> [4] https://github.com/unbit/uwsgi/issues/1550 >> >> -yoctozepto >>
I got response on https://github.com/unbit/uwsgi/issues/1550
Any oslo.middleware and/or quick testing platform setup experts are welcome to join the thread there. :-)
-yoctozepto
wt., 21 sty 2020 o 18:31 Radosław Piliszek radoslaw.piliszek@gmail.com napisał(a):
Ben wrote:
it looks like this is a uwsgi bug and not something we're doing wrong (other than recommending uwsgi ;-).
Precisely. Well, there is always a chance either side does something wrong until one acknowledges doing it wrong but if django and oslo.middleware can send CORS headers via mod_wsgi and both cannot via uWSGI, then it's uWSGI that's more suspicious. ;-)
Sean wrote:
is it somehting that we expect the wsgi server to add or the applciation? it seam like we use oslo midelware to do this dynmaically form the api code.
Wearing my web developer hat, I would say it's up to the application to do, in general, since different resources may need different CORS headers. In the contrived example of testing in CI, allowing anything for the sake of easy access, it does not really matter. :-)
Sean wrote:
but my only interaction in the past was setting it via the apache .htaccess file.
Yeah, any decent web server allows to add/remove/override headers.
Sean wrote:
they may be filtering them but i cant really find any documentaiton on uswgi and CORS configuration
Indeed that's what the linked bug report suggests as well as random googlable info. I wonder why nobody from uWSGI answered the bug call. :/
-yoctozepto
wt., 21 sty 2020 o 18:15 Sean Mooney smooney@redhat.com napisał(a):
On Tue, 2020-01-21 at 17:30 +0100, Ben Nemec wrote:
On 1/21/20 4:55 PM, Michael McCune wrote:
On Tue, Jan 21, 2020 at 5:37 AM Radosław Piliszek <radoslaw.piliszek@gmail.com mailto:radoslaw.piliszek@gmail.com> wrote:
Hi, Michael! Thanks for your interest. I was also surprised that it does not work. It looks simple enough to not break... Since I wrote the email, I did more research on how to tackle this problem. For now I posted a bug to devstack that CORS is out of reach with pure devstack [1].that sounds like a good first step.
Only keystone and placement can be configured to use mod_wsgi, others default to uwsgi (or eventlet, to be precise, but these are irrelevant). It's really either hacking browsers or hacking apache config to include relevant CORS headers.this is something that i think we need to know though, because if uWSGI has broken CORS support then we need to fix it or start advising against its usage.
Just to clarify, based on [0] it looks like this is a uwsgi bug and not something we're doing wrong (other than recommending uwsgi ;-). Is that correct?
is it somehting that we expect the wsgi server to add or the applciation? e.g. should the CORS headders be added by the apache/nginx/uwsgi or openstack.
but my only interaction in the past was setting it via the apache .htaccess file. https://enable-cors.org/server_apache.html you can also do it in nginx https://enable-cors.org/server_nginx.html
it seam like we use oslo midelware to do this dynmaically form the api code.
https://docs.openstack.org/oslo.middleware/latest/admin/cross-project-cors.h... so perhaps that is not executing or uswsgi si stripping the headers.
they may be filtering them but i cant really find any documentaiton on uswgi and CORS configuration
peace o/
[1] https://bugs.launchpad.net/devstack/+bug/1860287 -yoctozepto wt., 21 sty 2020 o 10:00 Michael McCune <elmiko@redhat.com <mailto:elmiko@redhat.com>> napisał(a): > > hi Radoslaw, > > i am also curious about this because i had thought we had CORS issued solved for uWSGI in the past, i will need to look around to find the conversations i was having. > > thanks for sharing your investigation, i think this is interesting. > > peace o/ > > On Fri, Jan 17, 2020 at 1:45 PM Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>> wrote: >> >> Fellow Devs, >> >> as you might have noticed I started taking care of openstack/js-openstack-lib, >> now under the openstacksdk umbrella [1]. >> First goal is to modernize the CI to use Zuul v3, current devstack and >> nodejs, still WIP [2]. >> >> As part of the original suite of tests, the unit and functional tests >> are run from browsers as well as from node. >> And, as you may know, browsers care about CORS [3]. >> js-openstack-lib is connecting to various OpenStack APIs (currently >> limited to keystone, glance, neutron and nova) to act on behalf of the >> user (just like openstacksdk/client does). >> oslo.middleware, as used by those APIs, provides a way to configure >> CORS by setting params in the [cors] group but uWSGI seemingly ignores >> that completely [4]. >> I had to switch to mod_wsgi+apache instead of uwsgi+apache to get past >> that issue. >> I could not reproduce locally because kolla (thankfully) uses mostly >> mod_wsgi atm. >> >> The issue I see is that uWSGI is proposed as the future and mod_wsgi >> is termed deprecated. >> However, this means the future is broken w.r.t. CORS and so any modern >> web interface with it if not sitting on the exact same host and port >> (which is usually different between OpenStack APIs and any UI). >> >> [1] https://review.opendev.org/701854 >> [2] https://review.opendev.org/702132 >> [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS >> [4] https://github.com/unbit/uwsgi/issues/1550 >> >> -yoctozepto >>
Those following github may have already discovered uWSGI is not the issue here.
The issue is devstack. Despite docs saying:
post-config - After OpenStack services have been initialized but still before they have been started.
The config happens after WSGI stuff is already started. In mod_wsgi case there is a difference in behavior because placement finally restarts apache2 which reloads keystone's config...
So anything set in post-config at the moment will not affect at least APIs (if uWSGI). Worth checking what else is affected and fixing...
-yoctozepto
wt., 21 sty 2020 o 20:43 Radosław Piliszek radoslaw.piliszek@gmail.com napisał(a):
I got response on https://github.com/unbit/uwsgi/issues/1550
Any oslo.middleware and/or quick testing platform setup experts are welcome to join the thread there. :-)
-yoctozepto
participants (4)
-
Ben Nemec
-
Michael McCune
-
Radosław Piliszek
-
Sean Mooney