remove default middlewares

[vincentsarago]

ref: #268

I don't think it's up to TiTiler to define application settings like CORS and response compression. This could be easily added by a user on their own application

from brotli_asgi import BrotliMiddleware

from titiler.main import app

app.add_middleware(BrotliMiddleware, minimum_size=0, gzip_fallback=True)

cc @drnextgis @geospatial-jeff @kylebarron

[drnextgis]

Totally agree. I was a little bit surprised to see this functionality (response compression) as part of the application itself. It is usually configured on the application server level.

[kylebarron]

I think this was originally done as part of the work to support Numpy tile output, because by default that data is uncompressed, and I think it was planned to only apply that as necessary but hadn't happened yet.

I don't know how much appetite there is for Titiler to really support Numpy tile output, but my stance is that if we want to truly support it, compression should be on by default for that output. Numpy output (especially with a mask) is quite large without compression, and any end user who wants to use both Numpy and other output formats will have the same issue as you: without digging into the application it seems hard to configure compression only for selected outputs.

I don't know fastapi/starlette as well as @vincentsarago and @geospatial-jeff, but I'd expect there's a way to apply middleware only to certain outputs, e.g. to be able to say "use this middleware only on outputs of type application/octet-stream". If that exists, then seems easy to implement "apply compression by default only for Numpy/uncompressed responses".

I was a little bit surprised to see this functionality (response compression) as part of the application itself

Not sure I follow, but if I understand correctly main.py is expected to be overridden by all except introductory end-users (for whom default compression on uncompressed file types is a benefit). So it would be very easy for you to reuse all of titiler without any given middleware by copying main.py yourself.

[vincentsarago]

just adding that to me it's not clear if headers get added to tile requests when using web map libraries 🤷‍♂️

[kylebarron]

just adding that to me it's not clear if headers get added to tile requests when using web map libraries 🤷‍♂️

I believe every network request a browser ever makes includes these Accept-Encoding headers. If I look at a random network request on this page, I can see plenty of default headers

Setting those headers is at the browser-level, not the JS level. Furthermore, it looks like it's impossible for JS to override that or any other "forbidden header" https://stackoverflow.com/a/63855008 https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name

[drnextgis]

Not sure I follow, but if I understand correctly main.py is expected to be overridden by all except introductory end-users (for whom default compression on uncompressed file types is a benefit).

I meant that compression might be configured (even for selected outputs) outside of Titiler. For example in case of k8s compression for Numpy tiles might be enabled by adding something like this to ingress controller here:

annotations:
  kubernetes.io/ingress.class: nginx
  nginx.org/server-snippets: |
    gzip on;
    gzip_types application/x-binary;

but I'd expect there's a way to apply middleware only to certain outputs

It seems there is no easy way for doing that.

[vincentsarago]

@kylebarron I get your point, but IMO, titiler shouldn't be responsible for the application. we ship a default app but I see it only as a demo. For production application I expect the user to add custom thing like middleware.

I think it would be pretty straight forward for a user to create a custom middleware that encode only npy response.

[kylebarron]

we ship a default app but I see it only as a demo

I think there's a tension here. If the default app is only a "demo" and shouldn't go into production, we should do things like removing the built Titiler Docker image. To me, having a docker image on Docker Hub says "this image is deploy-ready, just set some environment variables to your configuration". If that isn't the case, then that image shouldn't exist, because it'll make it easier for newcomers to shoot themselves in the foot.

[kylebarron]

It seems there is no easy way for doing that.

I think it would be pretty straight forward for a user to create a custom middleware that encode only npy response.

Those two arguments are contradictory...

[vincentsarago]

@kylebarron

Those two arguments are contradictory...

Indeed they are, and in fact @drnextgis is right, creating custom middleware that do no apply compression based on a media_type is not as easy.

I think there's a tension here. If the default app is only a "demo" and shouldn't go into production, we should do things like removing the built Titiler Docker image. To me, having a docker image on Docker Hub says "this image is deploy-ready, just set some environment variables to your configuration". If that isn't the case, then that image shouldn't exist, because it'll make it easier for newcomers to shoot themselves in the foot.

To me it's: hey there is a docker image, if you want to try you don't have to install anything. Like the GDAL docker image, you can use them in production but if you want something focused on performance, maybe you need to create one yourself

Here we have two choice:

• keep the default middleware, which re-compress body (only good when using uncompress data format like tiff and numpy-tile)
• remove the middleware and let the user figure out what to do

IMO, re-compressing data is bad. We can work on a solution that enables compression for some specific mediatype but until someone propose a good solution I'm in favour of removing the middleware.

cc @geospatial-jeff

[geospatial-jeff]

IMO slimmer is better. I don't think we should include things in the app by default that aren't necessarily required, and middleware definitely falls into this category.

[kylebarron]

Here we have two choice:

• keep the default middleware, which re-compress body (only good when using uncompress data format like tiff and numpy-tile)
• remove the middleware and let the user figure out what to do

Well I've never advocated for the first; re-compressing the body is unequivocally bad. My argument from the beginning of this issue is there's an option 3: figuring out how to add middleware to only compress uncompressed responses. After all there are plenty of non-image endpoints that return JSON and would be good to compress responses for.

Still, there's a tension here, are we planning to remove all the middlewares?? Then the default app won't even have CORS headers and won't be very usable.

IMO main.py is only used in the "demo" app; it's really not the "public export" of titiler. The public exports of titiler are all the things that main.py are referencing. Therefore having good defaults in main.py is a good thing, so that newcomers to the project can easily deploy something with sensible defaults without needing to customize everything.

[vincentsarago]

Therefore having good defaults in main.py is a good thing

a good default is IMO without the middleware! Mostly because, there isn't an easy way to know which response are already compressed (e.g a PNG could be encored without compression, a GeoTIFF could already be compressed...)

Then the default app won't even have CORS headers and won't be very usable.

We can argue about this. if you use the default viewer provided but the app it will work.