Re: #29752 Adding a ALLOWED_HOSTS_IGNORABLE_URLS setting

2018-09-14 Thread Adam Johnson
The snippet Matt posted is the same technique I've used for ages, albeit using the ec2-metadata library. I think it's perfectly fine as-is, the Host header EC2 uses is actually predictable as the EC2 Private IP. I don't think Django needs another

Re: #29752 Adding a ALLOWED_HOSTS_IGNORABLE_URLS setting

2018-09-14 Thread Mattia Procopio
What I usually do is rewriting the Host value at webserver level using one of the allowed when receiving healthchecks from a load balancer. This is not optimal and having a whitelist for some uris to allow requests without a valid host could make this specific thing easier -- You received

Re: #29752 Adding a ALLOWED_HOSTS_IGNORABLE_URLS setting

2018-09-14 Thread Collin Anderson
You might be able to handle this by a middleware that gets called early enough in the process (before CommonMiddleware) to avoid calling request.get_host(). A simple if request.path == '/statuscheck/': return HttpResponse() should work. As long as you never call request.get_host(), django doesn't

Re: #29752 Adding a ALLOWED_HOSTS_IGNORABLE_URLS setting

2018-09-14 Thread Matt Pegler
AWS will send a request to a specific path and make sure it receives a status 200 response. If the response status is not 200, it will consider that instance unhealthy and will not route traffic to that instance. The path can be anything that can be used as a signal that the application is running

Re: #29752 Adding a ALLOWED_HOSTS_IGNORABLE_URLS setting

2018-09-14 Thread Tim Graham
Sorry, I still don't understand what "whitelisting the health check path" looks like. Here's the snippet for anyone reading the thread after the pastebin expires. ALLOWED_HOSTS = ['ourdomain.com']EC2_PRIVATE_IP = Nonetry: # AWS provided magic service that returns metadata about the instance

Re: #29752 Adding a ALLOWED_HOSTS_IGNORABLE_URLS setting

2018-09-14 Thread Matt Pegler
We would find this valuable for the reason Jonas outlined. Health checks from AWS are sent without a host header, which causes the request to fail the host check. By whitelisting the health check path, it would simplify deployments to AWS and possibly others. Here's the workaround we use in

Re: #29752 Adding a ALLOWED_HOSTS_IGNORABLE_URLS setting

2018-09-14 Thread Tim Graham
What would be the value of that setting for your use case? On Friday, September 14, 2018 at 11:52:46 AM UTC-4, Jonas H wrote: > > Hi, > > I've started a discussion on https://code.djangoproject.com/ticket/29752 > to add a new ALLOWED_HOSTS_IGNORABLE_URLS setting. > > The setting can become handy

#29752 Adding a ALLOWED_HOSTS_IGNORABLE_URLS setting

2018-09-14 Thread Jonas H
Hi, I've started a discussion on https://code.djangoproject.com/ticket/29752 to add a new ALLOWED_HOSTS_IGNORABLE_URLS setting. The setting can become handy if you can't control the Host header sent to your application but still want to accept the request. An example of this is health checks

Re: Adding a bulk_save method to models

2018-09-14 Thread Raphael Michel
Hi, I'd be very careful about calling it bulk_save(), since calling it something with save() very strongly suggests that it calls pre_save or post_save signals. Best Raphael Am Fri, 14 Sep 2018 07:56:38 -0700 (PDT) schrieb Tim Graham : > > > I wanted to ask about naming of the new method.

Re: Adding a bulk_save method to models

2018-09-14 Thread Tim Graham
I wanted to ask about naming of the new method. Currently the proposed name is "QuerySet.bulk_save()" but I think it's a bit confusing since it uses QuerySet.update(), not Model.save(). It works similarly to QuerySet.bulk_update() from https://github.com/aykut/django-bulk-update but the

Re: RFC732 (a.k.a. brotli) support

2018-09-14 Thread Curtis Maloney
On 09/14/2018 08:24 PM, Aymeric Augustin wrote: Hello, I would like to be sure that Brotli is actually faster. In my experience, while decompression is fast, compression can be extremely slow. https://blogs.akamai.com/2016/02/understanding-brotlis-potential.html It's primarily tuned for

Re: RFC732 (a.k.a. brotli) support

2018-09-14 Thread Aymeric Augustin
Hello, I would like to be sure that Brotli is actually faster. In my experience, while decompression is fast, compression can be extremely slow. This is fine for static assets compressed by a build pipeline or at least when the compressed version is cached. It would be a problem for on-the-fly

Re: RFC732 (a.k.a. brotli) support

2018-09-14 Thread Adam Johnson
Sounds like a good idea to me. Would you be looking at merging any code from django-brotli, and have you been in contact with its creator and license holder Vasek Dohnal? And what kind of methods around Accept-Encoding are you imagining? On Fri, 14 Sep 2018 at 09:01, Johannes Hoppe wrote: >

RFC732 (a.k.a. brotli) support

2018-09-14 Thread Johannes Hoppe
Hi there, we all know the the wonderful GZip middleware that allows response compression. Which is great especially if you are serving large responses. Now gzip is only one of many supported encoding types supported by many browsers. The coolest kid on the block seems to be brotli right now.