Totally agree with this. So long as if you do support caching, compression, etc. you do so as specified.
Brian, you might want to go ahead and distribute your WSGI middleware as is anyway. It may be useful for small deployments, and who knows someone may take it up as a project and make it more efficient :-) A common gotcha with implementing content compression is forgetting about the Vary header. Make sure your middleware adds the Vary header with Accept-Encoding. Vary: Accept-Encoding This gives a hint to the cache that it shouldn't place compressed data in the same bucket as uncompressed data. If the service has already set a Vary header make sure you don't replace it, but modify it to include Accept-Encoding. -jOrGe W. On Mar 4, 2011, at 8:50 AM, Jay Pipes wrote: > On Thu, Mar 3, 2011 at 11:06 AM, Brian Lamar <[email protected]> > wrote: >> Part of the API specification says that the OpenStack API supports gzip >> compression in requests and responses. I have an extremely simple WSGI >> middleware implementation of this finished, but it does not support >> streaming which could potentially be non-performant for large responses. >> >> Keep in mind this is middleware and could be added/removed easily. >> >> My initial thought is to not attempt to include this type of middleware in >> OpenStack because gzip compression is best handled by a proxy system such as >> Nginx/Apache/etc. > > This is precisely the conclusion we came to in Glance. Let Squid or > Varnish handle caching, compression, etc, and let Glance focus on > registering image data. > > My 2 cents, > > -jay > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
