Version 22.6

Table of Contents


This is the second release of the version 22 release cycle. Version 22 will be "finalized" in the December long-term support version release.

What to know#

More details in the Changelog. Notable new or breaking features, and what to upgrade...

Automatic TLS setup in DEBUG mode#

The Sanic server can automatically setup a TLS certificate using either mkcert or trustme. This certificate will enable https://localhost (or another local address) for local development environments. You must install either mkcert or trustme on your own for this to work.

$ sanic --auto-tls --debug, auto_tls=True)

This feature is not available when running in ASGI mode, or in PRODUCTION mode. When running Sanic in production, you should be using a real TLS certificate either purchased through a legitimate vendor, or using Let's Encrypt.

HTTP/3 Server πŸš€#

In June 2022, the IETF finalized and published RFC 9114, the specification for HTTP/3. In short, HTTP/3 is a very different protocol than HTTP/1.1 and HTTP/2 because it implements HTTP over UDP instead of TCP. The new HTTP protocol promises faster webpage load times and solving some of the problems of the older standards. You are encouraged to read more about this new web technology. You likely will need to install a capable client as traditional tooling will not work.

Sanic server offers HTTP/3 support using aioquic. This must be installed:

pip install sanic aioquic
pip install sanic[http3]

To start HTTP/3, you must explicitly request it when running your application.

$ sanic --http=3
$ sanic -3

To run both an HTTP/3 and HTTP/1.1 server simultaneously, you can use application multi-serve introduced in v22.3.

$ sanic --http=3 --http=1
$ sanic -3 -1

Because HTTP/3 requires TLS, you cannot start a HTTP/3 server without a TLS certificate. You should set it up yourself or use mkcert if in DEBUG mode. Currently, automatic TLS setup for HTTP/3 is not compatible with trustme.

πŸ‘Ά This feature is being released as an EARLY RELEASE FEATURE. It is not yet fully compliant with the HTTP/3 specification, lacking some features like websockets, webtransport, and push responses. Instead the intent of this release is to bring the existing HTTP request/response cycle towards feature parity with HTTP/3. Over the next several releases, more HTTP/3 features will be added and the API for it finalized.

Consistent exception naming#

Some of the Sanic exceptions have been renamed to be more compliant with standard HTTP response names.

  • InvalidUsage >> BadRequest
  • MethodNotSupported >> MethodNotAllowed
  • ContentRangeError >> RangeNotSatisfiable

All old names have been aliased and will remain backwards compatible.

Current request getter#

Similar to the API to access an application (Sanic.get_app()), there is a new method for retrieving the current request when outside of a request handler.

from sanic import Request


Improved API support for setting cache control headers#

The file response helper has some added parameters to make it easier to handle setting of the Cache-Control header.


Custom loads function#

Just like Sanic supports globally setting a custom dumps, you can now set a global custom loads.

from orjson import loads

app = Sanic("Test", loads=loads)

Deprecations and Removals#

  1. REMOVED - Applications may no longer opt-out of the application registry
  2. REMOVED - Custom exception handlers will no longer run after some part of an exception has been sent
  3. REMOVED - Fallback error formats cannot be set on the ErrorHandler and must only be set in the Config
  4. REMOVED - Setting a custom LOGO for startup is no longer allowed
  5. REMOVED - The old stream response convenience method has been removed
  6. REMOVED - AsyncServer.init is removed and no longer an alias of

Thank you#

Thank you to everyone that participated in this release: :clap:

@ahopkins @amitay87 @ashleysommer @azimovMichael @ChihweiLHBird @kijk2869 @prryplatypus @SaidBySolo @sjsadowski @timmo001 @zozzz

If you enjoy the project, please consider contributing. Of course we love code contributions, but we also love contributions in any form. Consider writing some documentation, showing off use cases, joining conversations and making your voice known, and if you are able: financial contributions.