Django http2

Django http2 DEFAULT

Django HTTP2 Middleware

<scriptsrc="{% http2static 'js/jquery.min.js' %}"></script><!-- Preload header for js/jquery.min.js will be automatically attached to response -->

This is a small middlware for Django v2.0+ to automatically generate preload headers from staticfiles used in template rendering, with support for using to send cached preload headers in advance of the actual response being generated. The preload headers alone provide large speed boost, but pre-sending the cached headers in advance of view execution is the real advantage that this library provides.

It's also built to support modern security features like Content Security Policy using , it sends in preload headers correctly so that preloads aren't rejected by your CSP policy if they require a nonce. Support for automatically generating and attaching CSP hashes for staticfiles and inline blocks is also planned in the near future.

It's not yet production-ready (I'll put it on PyPI if/when it ever is), but for now it's easily installable by cloning it into your apps folder, and the codebase is small enough to be quickly reviewed and customized to a project's needs.


How it works

It works by providing a templatetag that serves as a drop-in replacement for , except it records all the urls used while rendering the template in .

The http2 middleware then transforms the list of urls into a full HTTP preload header, which is then attached to the response. When , the first response's preload headers will be cached and automatically sent in advance during later requests (using to send them before the view executes). Upstream servers like Nginx and CloudFlare can then use these headers to do HTTP2 server push, delivering the resources to clients before they are requested during browser parse & rendering. With TCP fast-open, TLS 1.3, and HTTP2 server push, it's now possible to have entire pageloads with only 1 round-trip, now all we need are cache-digests and QUIC and then we'll be at web nirvana .

HTTP2 server-push

When preload headers are sent fast and is enabled in , upstream servers like Nginx or Cloudflare HTTP2 will usually finish server pushing all the page resources not only before the browser requests them, but even before the view is finished executing, providing a 100ms+ headstart to static file loading in some cases. When enabled it's very cool to look at the network waterfall visualization and see your page's statcifiles finish loading together, a full 50ms+ before the HTML is even returned from Django!

Unfortunately, while shiny and exciting, this wont necessarily make your site faster for real-world users. In fact, it can sometimes make sites slower because after the first visit, users have most of the resources cached anyway, and pushing uneeded files on every request can waste network bandwidth and use IO & CPU capacity that otherwise would've gone towards loading the actual content. You should toggle the config options while testing your project to see if server push provides real-world speed gains, or use the recommended settings listed below that provide speed gains in most cases without the risk of wasting bandwidth to push uneeded resources. There are some cases where HTTP2 push is still worth it though, e.g. if you have to push a small bundle of static files for first paint and most of your users are first-time visitors without your site cached.

HTTP2 server-push will eventually become the optimal method of page delivery once cache-digests are released (improving both latency and bandwidth use). Read these articles and the links within them to learn more about HTTP2, server push, and why cache digests are an important feature needed to make server-push worth it:

This library is still useful without server push enabled though, as it's primary function is to collect statifiles and send them as preload headers in parallel before the Django views finish executing, which can provide a 100ms+ headstart for the browser to start loading page content in many cases. The optimal recommended settings for maximum speed gain (as of 2019/07) are to send preload headers, cache them and send them in advance, but don't enable until cache-digest functionality is released in most browsers.

Install:

  1. Clone this repo as into your project folder next to as a new django app called "http2":
cd /opt/your-project/project-django/ git clone https://github.com/pirate/django-http2-middleware http2
  1. Add to your list in :
MIDDLEWARE= [ ... 'csp.middleware.CSPMiddleware', # (optional if you use django-csp, it must be above the http2 middleware)'http2.middleware.HTTP2Middleware', # (add the middleware at the end, but before gzip) ] # (adding "http2" to INSTALLED_APPS is not needed)
  1. Add the required configuration options to your :
HTTP2_PRELOAD_HEADERS=TrueHTTP2_PRESEND_CACHED_HEADERS=TrueHTTP2_SERVER_PUSH=False
  1. (Optional) Add the templatag as a global template builtin in :
    This will make availabe in templates without needing at the top.
TEMPLATES= [ { ... 'OPTIONS': { ... 'builtins': [ ... 'http2.templatetags', ], }, }, ... ]
  1. (Optional if using ) Include nonces on any desired resource types in :
    Generated preload headers will automatically include this nonce using .
# add any types you want to use with nonce-validation (or just add it to the fallback default-src)CSP_DEFAULT_SRC= ("'self'", ...) CSP_INCLUDE_NONCE_IN= ('default-src', ...)

Usage

Just use the tag instead of anytime you want to have a resource preloaded.

<!-- It's still a good idea to put normal html preload link tags at the top of your templates in addition to using the auto-generated HTTP headers, though it's not strictly necessary --><linkrel="preload" as="style" href="{% http2static 'css/base.css' %}" crossoriginnonce="{{request.csp_nonce}}"><linkrel="preload" as="script" href="{% http2static 'vendor/jquery-3.4.1/jquery.min.js' %}" crossoriginnonce="{{request.csp_nonce}}"> ... <!-- Place the actual tags anywhere on the page, they will likely already be pushed and downloaded by time the browser parses them. --><linkrel="stylesheet" href="{% http2static 'css/base.css' %}" type="text/css" crossoriginnonce="{{request.csp_nonce}}"><scriptsrc="{% http2static 'vendor/jquery-3.4.1/jquery.min.js' %}" type="text/javascript" crossoriginnonce="{{request.cscp_nonce}}"></script>

Don't use for everything, just use it for things in the critical render path that are needed for the initial pageload. It's best used for CSS, JS, fonts, and icons required to render the page nicely, but usually shouldn't be used for non-critical footer scripts and styles, async page content, images, video, audio, or other media.

Configuration

Recommended Settings

These settings provide the most speed gains for 90% of sites, though it's worth testing all the possibilities to see the real-world results for your project.

HTTP2_PRELOAD_HEADERS=TrueHTTP2_PRESEND_CACHED_HEADERS=TrueHTTP2_SERVER_PUSH=False

Configuration

Values: []/

Attach any urls used templates in an auto-generated HTTP preload header on the response. Disable this to turn off preload headers and disable the middleware entirely, this also prevents both header caching and http2 server push.

Values: []/

Cache first request's preload urls and send in advance on subsequent requests. Eanble this to cache the first request's generated preload headers and use on subsequent requests to send the headers early before the view starts executing. Disable this to use normal HTTPResponses with the preload headers attached at the end of view execution.

Values:/[]

Allow upstream servers to server-push any files in preload headers. Disable this to add to all the preload headers to prevent upstream servers from pushing resources in advance.
Keeping this set to is recommended until cache-digests are sent by most browsers.

Configuration

There are many ways to implement Content Security Policy headers and nonces with Django, the most popular for django is , which is library maintained by Mozilla. This library is built to be compatible with Mozilla's , but it's not required to use both together. You can find more info about configuring Django to do CSP verification here:

Webserver Configuration

In order to use HTTP2 server push, you need a webserver in front of Django that reads the preload headers and pushes the files. Cloudflare has a GUI control panel option to enable server push, and nginx can do it with only one extra line of config:

server { listen443 ssl http2; http2_push_preload on; # nginx will automatically server-push anything specified in preload headers ... }

See more info and nginx http2 options here:

Verifying it works

Responses can be served in three different ways when using . You can inspect which way is used for a given response by looking at the header attached to the response. If all the options are enabled, it takes two initial requests after enabling the middleware and starting Django for the cache to warm up, one to detect the content type, and one to build the list of resource URLs used by the template:

  1. The first request to a given URL has no preload headers sent in advance (). It's used to confirm that the request and response are and not a JSON API request, file download, or other non-html type that shouldn't have preload headers attached.
  2. The second request has preload headers but only attaches them after the response is generated (). It's used build the initial cache of preload urls for the given by collecting urls used by tags during template rendering.
  3. If , the third request (and all requests after that) send the cached headers immediately before the response is generated (). If presending cached headers is disabled, then wont be used to pre-send headers before the view, and preload headers will be attached after the response as usual in mode.

Start runserver behind nginx and reload your page 4 times while watching the dev console to confirm the cache warms up properly and later requests receive server-pushed resources. If everyting is working correctly, the third pageload and all subsequent loads by all users should show up with the response header, and pushed resources should appear significantly earlier in the network timing watefall view.

You can inspect the preload performance of a given page and confirm it matches what you expect for its mode using the network requests waterfall graph in the Chrome/Firefox/Safari dev tools.

Requires:Requires:Requires:

If you set and , responses will all be sent in mode, which is the recommended mode until cache digests become available in most browsers.

Further Reading

Docs & Articles

Similar Projects

After making my own solution I discovered great minds think alike, and a few people have done exactly the same thing before me already! It's crazy how similarly we all chose to implement this, everyone used a drop-in replacement for , I guess it goes to show that Django is particularly designed well in this area, because there's one obvious way to do things and everyone independently figured it out and implemented robust solutions in <200LOC.

However, none of these support CSP policies (which require adding nonces to the preload headers), or use to send push headers before the view executes, so in some ways this project takes adventage of the available HTTP2 speed-up methods to the fullest degree out of the 4.

Project Status

Consider this library "beta" software, still rough in some areas, but used in production for 6+ months on several projects. It's not on PyPi tet, I'll publish it once it's nicer and has more tests. For now it should be cloned into your Django folder, or used piecewise as inspiration for your own code.

Once HTTP2 cache digests are finalized, server push will (2020 Edit: lol) become the fastest way to deliver assets, and this project will get more of my time as we integrate it into all our production projects at @Monadical-SAS. To read more about why cache digests are critical to HTTP2 server push actually being useful, this article is a great resource:

Bonus Material

Did you know you can run code after a Django view returns a response without using Celery, Dramatiq, or another background worker system? Turns out it's trivially easy, but very few people know about it.

defmy_view(request): ... returnHttpResponseWithCallback(..., callback=some_expensive_function) classHttpResponseWithCallback(HttpResponse): def__init__(self, *args, **kwargs): self.callback=kwargs.pop('callback', None) super().__init__(*args, **kwargs) defclose(self): super().close() self.callbackandself.callback(response=self)

In small projects it's perfect for sending signup emails, tracking analytics events, writing to files, or any other CPU/IO intensive task that you don't want to block the user on. In large projects, this is an antipattern because it encourages putting big blocking IO or CPU operations in these "fake" async request callbacks. The callbacks don't actually run asyncronously (like Celery), they don't provide any free performance improvement on the main server thread, in they just hide some operations outside of the normal request/response lifecycle and make it hard to track down latency issues. You probably don't want to block main Django worker threads with things that would be better handled in the background, as it'll greatly reduce the number of simultaneous users your servers can handle.

For a full example demonstrating this library and more, check out this gist: django_turbo_response.py.

Sours: https://github.com/pirate/django-http2-middleware

Enable HTTP/2 support with Apache

NOTE: We are in the process of modifying the file structure and configuration for many Bitnami stacks. On account of these changes, the file paths stated in this guide may change depending on whether your Bitnami stack uses native Linux system packages (Approach A), or if it is a self-contained installation (Approach B). To identify your Bitnami installation type and what approach to follow, run the command below:

The output of the command indicates which approach (A or B) is used by the installation, and will allow you to identify the paths, configuration and commands to use in this guide. Refer to the FAQ for more information on these changes.

Bitnami stacks ship with the mod_http2 module installed, but it is not enabled by default. To enable this module, follow these instructions. Once the module is active, follow the steps below:

Approach A: Bitnami installations using system packages

  • Add the following lines in the default Apache HTTP virtual host configuration file at /opt/bitnami/apache2/conf/bitnami/bitnami.conf, inside the default VirtualHost directive, so that it looks like this:

  • Add the following lines in the default Apache HTTPS virtual host configuration file at /opt/bitnami/apache2/conf/bitnami/bitnami-ssl.conf, inside the default VirtualHost directive, so that it looks like this:

  • Add the following lines in any Apache virtual host file defined inside the /opt/bitnami/apache2/conf/vhosts/ directory, inside the default VirtualHost directive for each file, so that it looks like this:

    NOTE: Replace the PORT placeholder with the port number used by the virtual host.

  • After modifying the Apache configuration files, restart Apache to apply the changes.

Approach B: Self-contained Bitnami installations

  • Add the following lines in the default Apache virtual host configuration file at /opt/bitnami/apache2/conf/bitnami/bitnami.conf, inside the default VirtualHost directives, so that it looks like this:

    Repeat the above change for any other virtual hosts you may have defined.

  • After modifying the Apache configuration files, restart Apache to apply the changes.

Sours: https://docs.bitnami.com/ibm/infrastructure/django/administration/enable-http2-apache/
  1. Trackitt h1b
  2. Batman welcome mat
  3. Female sound effect

HTTP2 Server Push with Django?

Bobby Mozumder's profile photo

Bobby Mozumder

unread,
Jun 28, 2016, 3:46:26 PM6/28/16

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

You do not have permission to delete messages in this group

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to Django users

Does anyone know of an http/2 server with server push capability that can work with Django?

It looks like nginx supports http2 with uWSGI, but it doesn’t actually support server push capability.

I also found the h2o server, but it doesn’t look like it supports uWSGI yet..

Any other options out there for http2 server push, preferably with cache-aware server push?

(I’d set http “Link” headers in my app to direct server push.)

-bobby

Fabio C. Barrionuevo da Luz's profile photo

Fabio C. Barrionuevo da Luz

unread,
Jun 28, 2016, 4:10:37 PM6/28/16

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

You do not have permission to delete messages in this group

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to [email protected]

as far as I know, there is still no any web server that fully implements the "push" capability from HTTP2 specification.

let me know if any web server now implements "push" capability completely

Bobby Mozumder's profile photo

Bobby Mozumder

unread,
Jun 28, 2016, 4:16:04 PM6/28/16

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

You do not have permission to delete messages in this group

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to [email protected]

Mario R. Osorio's profile photo

Mario R. Osorio

unread,
Jun 28, 2016, 7:34:45 PM6/28/16

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

You do not have permission to delete messages in this group

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to Django users

Here are some resources:

Bobby Mozumder's profile photo

Bobby Mozumder

unread,
Jun 28, 2016, 7:48:40 PM6/28/16

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

You do not have permission to delete messages in this group

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to [email protected]

Alcides Viamontes E's profile photo

Alcides Viamontes E

unread,
Jul 1, 2016, 10:35:27 PM7/1/16

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

You do not have permission to delete messages in this group

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to Django users

Take a look to ShimmerCat and it's Django support: 

https://www.shimmercat.com/en/info/articles/guides-django/

ShimmerCat's raison d'etre is to be a viable alternative to CDNs for lowering the effects of latency in webpages. But regarding your question: 

- It implements HTTP/2 Push

- It implements cache digests via Cookies. 

As of shimmercat.com, it is run on ShimmerCat + uWSGI and it has been so for more than six months now. 

Sours: https://groups.google.com/
HTTP/2 Push is Being Removed, let us discuss

question

I created the Azure web app container service. Where I am trying to build redis image along with private Django channels image. I am getting the below error and the container is stopping. These are my logs in the web app container.

2020-07-08T01:24:20.575Z ERROR - multi-container unit was not started successfully
2020-07-08T01:24:20.585Z INFO - Container logs from kiwi-message-delivery_redis_0_530c2465 = 2020-07-08T01:20:34.613961396Z 1:C 08 Jul 2020 01:20:34.613 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2020-07-08T01:20:34.622739022Z 1:C 08 Jul 2020 01:20:34.622 # Redis version=6.0.5, bits=64, commit=00000000, modified=0, pid=1, just started
2020-07-08T01:20:34.623124845Z 1:C 08 Jul 2020 01:20:34.622 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
2020-07-08T01:20:34.708013928Z 1:M 08 Jul 2020 01:20:34.707 Running mode=standalone, port=6379.
2020-07-08T01:20:34.708440853Z 1:M 08 Jul 2020 01:20:34.708 # Server initialized
2020-07-08T01:20:34.708763573Z 1:M 08 Jul 2020 01:20:34.708 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add &#39;vm.overcommit_memory = 1&#39; to /etc/sysctl.conf and then reboot or run the command &#39;sysctl vm.overcommit_memory=1&#39; for this to take effect.
2020-07-08T01:20:34.709083492Z 1:M 08 Jul 2020 01:20:34.708 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command &#39;echo never &gt; /sys/kernel/mm/transparent_hugepage/enabled&#39; as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
2020-07-08T01:20:34.709659826Z 1:M 08 Jul 2020 01:20:34.709
Ready to accept connections
2020-07-08T01:20:37.186901553Z 1:M 08 Jul 2020 01:20:37.186 # Possible SECURITY ATTACK detected. It looks like somebody is sending POST or Host: commands to Redis. This is likely due to an attacker attempting to use Cross Protocol Scripting to compromise your Redis instance. Connection aborted.
2020-07-08T01:21:38.792293857Z 1:M 08 Jul 2020 01:21:38.792 # Possible SECURITY ATTACK detected. It looks like somebody is sending POST or Host: commands to Redis. This is likely due to an attacker attempting to use Cross Protocol Scripting to compromise your Redis instance. Connection aborted.
2020-07-08T01:22:39.333304667Z 1:M 08 Jul 2020 01:22:39.333 # Possible SECURITY ATTACK detected. It looks like somebody is sending POST or Host: commands to Redis. This is likely due to an attacker attempting to use Cross Protocol Scripting to compromise your Redis instance. Connection aborted.
2020-07-08T01:23:40.870740206Z 1:M 08 Jul 2020 01:23:40.870 # Possible SECURITY ATTACK detected. It looks like somebody is sending POST or Host: commands to Redis. This is likely due to an attacker attempting to use Cross Protocol Scripting to compromise your Redis instance. Connection aborted.

2020-07-08T01:24:24.447Z INFO - Container logs from kiwi-message-delivery_channels_0_530c2465 = 2020-07-08T01:20:43.833567596Z 2020-07-08 01:20:43,832 INFO Starting server at tcp:port=8000:interface=0.0.0.0
2020-07-08T01:20:43.834721057Z 2020-07-08 01:20:43,834 INFO HTTP/2 support not enabled (install the http2 and tls Twisted extras)
2020-07-08T01:20:43.841353805Z 2020-07-08 01:20:43,840 INFO Configuring endpoint tcp:port=8000:interface=0.0.0.0
2020-07-08T01:20:43.843852936Z 2020-07-08 01:20:43,843 INFO Listening on TCP address 0.0.0.0:8000

2020-07-08T01:24:29.155Z INFO - Stopping site kiwi-message-delivery because it failed during startup.

I tried with enabling the HTTP 2.0 in Web App configuration. But not working.

Anyone please help me with this.

azure-webappsazure-container-instancesazure-webapps-developmentazure-container-registrySours: https://docs.microsoft.com/answers/questions/43991/http2-support-not-enabled-install-the-http2-and-tl.html

Http2 django

Django HTTP/2 Server Push redirects

A Django middleware that adds a HTTP/2 Server Push header to plain Django redirect responses.

This approach requires Django to be proxied by a server with HTTP/2 Server Push support. E.g. , with enabled or a CDN services like Cloudflare.

Installation

This package is available on PyPI and can be installed with :

pip install django-push-redirect

Configuration

First configure your webserver to enable HTTP/2 and enable server push.

This looks something like this for nginx:

server{listen443sslhttp2;listen[::]:443sslhttp2;[email protected]{proxy_set_headerX-Forwarded-Proto$scheme;http2_push_preloadon;...}}

The configuration for Apache and other servers/services is left as an exercise for the reader (in other words, I don't know, please contribute if you do!).

Now make sure Django is able to detect if a request is secure by configuring the setting, e.g.:

SECURE_PROXY_SSL_HEADER=('HTTP_X_FORWARDED_PROTO','https')

Then add to your project's , make sure it's before Django's :

MIDDLEWARE=[...'push_redirect.middleware.Http2ServerPushRedirectMiddleware','django.middleware.common.CommonMiddleware',...]

This middleware adds the header on redirect responses that should be preloaded.

If everything is configured correctly you should see that redirects no longer require an extra request the the webserver.

Response opt-out

It is possible for a response to explicitly opt-out from the having a header added. This is done by setting to on the object, e.g.:

defopt_out(request):response=HttpResponseRedirect("/")response.allow_push_redirect=Falsereturnresponse

Inspiration / References

Sours: https://pypi.org/project/django-push-redirect/
Шаблон Django проекта с конфигами для быстрого разворачивания сервера

.

Similar news:

.



64 65 66 67 68