Re: Adding SASL support to Pylibmc backend

[Jason Mayfield]

It's funny you posted this today, as I was just about to post
something similar, for the same genesis:  Heroku.

When installing pylibmc, it wants to compile, which blows up because
of missing headers in the standard Heroku environment.  However, they
are in the process of testing an update to their Python support such
that if they detect that you are loading pylibmc, they will bootstrap
libmemcached for you and everything is gravy, at least as far as
compiling goes.

Of course, you still need to have a SASL client to talk to the single
memcached provider currently on Heroku, so you also need to use a
custom backend for it.  I'd written one myself, wrapping Django's
PylibMCCache backend and overriding the _cache method to pass in the
username and password parameters (which on Heroku are provided as
environment variables once you turn on the memcache add-on).  One of
the guys at Heroku has also written that support into a fork of the
external django-pylibmc module as well.

What all this blather is leading up to is my support (such as it is)
for the idea of including the username and password parameters in the
PylibMCCache client.  I'd be happy to assist Walter in doing so.

Although to be devil's advocate, I've basically just proven that we
don't strictly *need* this change to core (given the existence of the
external backend).  Plus, of course, since Heroku is on EC2, we can
also use other external memcache servers using the vanilla client; for
example, Amazon's ElasticCache.

Best,
Jason

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django POST Broken

[Jason Mayfield]

My company uses the nginx + uwsgi combination extensively (well, so far it's 
the stack serving Django on 6-ish servers) and haven't ever had this particular 
problem.  For reference, here's our (stock) uwsgi_params file:

uwsgi_param  QUERY_STRING   $query_string;
uwsgi_param  REQUEST_METHOD $request_method;
uwsgi_param  CONTENT_TYPE   $content_type;
uwsgi_param  CONTENT_LENGTH $content_length;

uwsgi_param  REQUEST_URI$request_uri;
uwsgi_param  PATH_INFO  $document_uri;
uwsgi_param  DOCUMENT_ROOT  $document_root;
uwsgi_param  SERVER_PROTOCOL$server_protocol;

uwsgi_param  REMOTE_ADDR$remote_addr;
uwsgi_param  REMOTE_PORT$remote_port;
uwsgi_param  SERVER_PORT$server_port;
uwsgi_param  SERVER_NAME$server_name;

- Jason

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.