Имеется своя реализация HTTP-сервера на МК.
Статическое содержимое сервера хранится во FLASH-памяти программ МК. Так как планируется, что объём этой статики будет приличный, то файлы сервера хранятся в основном в сжатом виде (gzip/deflate).
Но отдавать содержимое в сжатом виде сервер может только если клиент сообщил, что он поддерживает эти методы сжатия.
Если среди методов сжатия, поддерживаемых клиентом, нет методов, в которых контент хранится на сервере, то перед отправкой данных клиенту, сервер должен их распаковать.
А распаковка (gzip/deflate) - это ресурсоёмкая операция. В частности для распаковки gzip необходимо как минимум ~35кБ ОЗУ. И что-то я думаю - это слишком жирно для моего девайса (ОЗУ только внутренняя).
В связи с вышеизложенным вопрос к сообществу, кто в курсе:
Можно-ли ожидать, что в настоящее время любой HTTP-клиент в обязательном порядке поддерживает методы Accept-Encoding: gzip или deflate? И нету, и в ближайшем будущем не будет современных браузеров не поддерживающих их?
И можно-ли в таком случае не реализовывать распаковщик в составе прошивки устройства, надеясь, что всегда сжатые файлы можно будет отправить клиенту "как есть"?
Интересуют только клиенты - браузеры, так как предполагается, что этот HTTP-сервер будет смотреть только человек, никаких роботов.
Я насколько смог проверил все доступные мне браузеры (3шт. под виндой, 2 под Андроидом, 2 под симбиан) - все поддерживают gzip,deflate.

На 19:30 12.01.2017 все поддерживают gzip
Но всегда можно отправить клиенту простую страницу с текстом
Ваш броузер фиговый
если в заголовке нет поддержки gzip

Похоже так и буду делать. Тем более, что других мнений никто не высказал. Странно - неужто никто более тут не работает с HTTP?

Лично я бы просто поставил внешнюю флешку для содержимого веб сервера и не заморачивался бы.
Ну либо да, в инструкции к девайсу так и писать: используйте браузер такой-то - он точно совместим. А остальные на свой страх и риск.

Вносить изменения в схемотехнику крайне не желательно. Этот вариант оставим на крайний случай.