Per-Entity Metadata Working Group

[Brent Putman <>]

On 10/18/16 6:39 PM, Cantor, Scott wrote:

I don't know what metadata clients support HTTP Compression. I assume
Shibboleth does but I don't know that for a fact.

I assume the IdP supports it uniformly, but I don't know. 

Yes, the HttpClient instances used in the Shibboleth IdP's metadata resolvers do support compression by default, for the "gzip" and "deflate" schemes.  I don't believe there's anything further to be done.

Assuming Shibboleth handles HTTP Compression just fine, I wouldn't
expect too many problems if we enabled apache but a few deployments
will experience problems, I'm sure. The fallback aggregate would come
in handy here. Does anyone know how to configure apache such that the
fallback aggregate is NOT compressed on the fly (yet everything else
is)?

mod_deflate has many options. [1]  (Despite its name, it's really now about gzip compression). You can scope whether it compresses or not, by applying directives to a Location or Directory block, etc, just like any other httpd directives.

Isn't compression just negotiated? You make the resources available in that form and Apache will serve up whatever the client handles. Shouldn't be any breakage with it.

That is my understanding also.  Client sends for example HTTP request header:  "Accept-Encoding: gzip,deflate".  Server responds with for example HTTP response header: "Content-Encoding: gzip".  Each does the right thing depending on what it got from the other.


[1] http://httpd.apache.org/docs/current/mod/mod_deflate.html