We have used in the last article the mediastreamvalidator from Apple to create a report of recommendations for our stream. Now we start fixing this by starting with the following message:

The server MUST deliver playlists using gzip content-encoding

• All Variants
• Master Playlist

I was wondering about this message, because the specification tells me something different:

HTTP servers SHOULD transfer text files — such as Playlists and WebVTT segments — using the “gzip” Content-Encoding if the client indicates that it is prepared to accept it.

Is it now a MUST or a SHOULD? Nevertheless we’ll check how to fix this.

Update: The mediastreamvalidator is not validating it against the RFC specification. It’s validating it against Apples “HLS Authoring Specification for Apple Devices“.

NGINX

Since I’m using NGINX as my webservice, it has built in support for gzip compression. We just need to enable it by adding the following lines in the nginx.conf:

gzip on;

gzip_vary on;

Enables or disables inserting the “Vary: Accept-Encoding” response header field if the directives gzip, gzip_static, or gunzip are active.

gzip_types application/vnd.apple.mpegurl;

Enables gzipping of responses for the specified MIME types in addition to “text/html”.
application/vnd.apple.mpegurl is the official MIME type for m3u8 playlist files (specified in chapter 4 of RFC 8216). You should also verified that his MIME type is used and correctly sent into the browser. If not, you should verify if the following line is available in your mime.types file:

application/vnd.apple.mpegurl m3u8;

Restart and Re-Test

After a restart of NGINX (or configuration re-load) we can easily re-execute the mediastreamvalidator and the hlsreport.py to create a new report. Now this point is no longer in your MUST fix list.