1. fanstatic
  2. fanstatic
  3. fanstatic
  4. Issues
Issue #27 resolved

alternative domains for resources

created an issue

Even when not serving a resource over a CDN, it might be useful to be able to specify that resources (but only resources) should be requested from an alternative (sub) domain, such as static.example.com, where another instance of Fanstatic is running by itself (without underlying WSGI app).

This can improve performance if the dynamic server sends out cookies; if the resources are hosted on the same domain those cookies will be sent back by the client to the static URLs as well. If the static URLs happen to be on another server that never sends out cookies this won't be the case.

Comments (2)

  1. Jan-Jaap Driessen

    The `static.example.com` base_url can be configured and could even be served by the same WSGI instance as the one where the resource URLs are injected. This way, you don't have two fanstatic instances to keep in sync.

  2. Log in to comment