Here is our vassal config (for our public process):

[uwsgi]
socket = :9311
protocol = http
processes = 1
lazy = true
vacuum = true
no-default-app = true
memory-report = true
plugins = python
paste = config:/etc/barbican/barbican-api-paste.ini

So it does seem that the 'protocol' line should be selecting http mode then, in 
which case your patch could work for our non-nginx deployments.

BTW, we launch the app this way:

uwsgi --master --die-on-term --emperor /etc/barbican/vassals --logto 
/var/log/barbican/barbican-api.log --stats localhost:9314

Note that we haven't attempted to tune uWSGI for performance yet. :)

Thanks,
John

________________________________________
From: [email protected] [[email protected]] on behalf of 
Roberto De Ioris [[email protected]]
Sent: Monday, March 31, 2014 8:44 AM
To: uWSGI developers and users list
Subject: Re: [uWSGI] Multiple request headers with same name

> We actually haven't been using a process in front of uWSGI until our
> internal deployment efforts, which use Repose
> (http://www.openrepose.org/). I suppose we hadn't noticed this issue prior
> to that because we were using Keystone middleware to form the auth header
> info (including combining the XROLES header values).
>
> At any rate it seems we should be using native http mode for our
> deployments, thank you for the correction!
>
> Thanks,
> John


I am not sure this is the right approach (unless i am missing something)

Can you paste a full vassal config ?

uWSGI speaks various protocols, CGI-based ones (uwsgi, FastCGI, SCGI,
mongrel2) and HTTP based ones (http, https)

the first ones requires some form of proxy that will need to assemble
duplicate headers (nginx for example), while the others need to assemble
them (even when behind a proxy). The patch i wrote is for addressing this
second issue, but if you are using --socket, you are using the uwsgi
protocol (unless you forced another protocol with the --protocol option)
so it is your proxy that need to assemble them.

--
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to