gzip в браузерах

[Stilet]

Привет, народ.
Тут вычитал что современные браузеры поддерживают сжатий gzip контент для ускорения передачи данных.
Насколько это правда, и как тогда я смогу использовать эту возможность для передачи сжатого от моего сервера к браузеру?
Предположим я сжал в своем сервере gzip модулем контент и передаю браузеру, как указать ему что это сжатый контент, и его нужно еще распаковать?
В JS есть средства для этого или сами браузеры расчехляются, как только получают сжатый контент?

[Xardas]

Если браузер поддерживает сжатие, то контент сам должен расчехлиться.

Тут вроде хорошо описан процесс

[Stilet]

Ага, т.е. есть шанс таким образом сжимать данные, передаваемые через AJAX с соответствующим НТТР хедером и браузер сам распознает необходимость разжатия.
Это хорошо, это можно использовать для передачи больших словарей в начале сессии.

[Человек_Борща]

Чтобы клиент узнал что вы ему gzip заслали, надо в шапку от сервера вставить:
Content-Encoding: gzip и запаковать этим алгоритмом данные.

Чтобы серверу знать, узнает ли клиент gzip или нет, в шапке клиента должно быть:
Accept-Encoding: gzip, deflate

[Stilet]

Понял. Попробую, и подумаю где это стоит применить в проекте, а где нет.
За ответы спасибо

[Человек_Борща]

Попробую, и подумаю где это стоит применить в проекте, а где нет.

Везде... где только можно.

Просто говорите серверу, что способны разжать gzip, и от этого отталкиваетесь, и получаете куда меньший входящий/исходящий(если сами пакуете) трафик.

Content-Encoding: gzip //Говорим, что сами запаковали в GZIP
Accept-Encoding: gzip, deflate //Говорим что умеем кушать GZIP

Могут быть как у сервера, так и у клиента в шапках.

[Stilet]

и получаете куда меньший входящий/исходящий(если сами пакуете) трафик.

А так же нагрузку на сервер в результате операций сжатия
Не, тут надо подумать. Если передаваемый контент маленький то и сжимать его не нужно - от сжатия маленького контента я кстати только потеряю в трафике.
Другое дело - мне в одном из случаек корче треба передать огромный (от 1000 до 10000) строк справочник клиенту, который будет активен в процессе всего сеанса. Вот его стоит жать, и нагрузка на сервер будет не так частая, потому как предполагается что сеанс не будет прерываться весь рабочий день.

[Человек_Борща]

С этим согласен, но можно же по умному сделать. Записать эдакий "разум" в код. Чтобы по размеру данных(не сжатых) определять минимум когда уже требуется сжатие дабы уменьшить объем трафика ну на 20%(с потолка).... при меньших размерах не сжатой инфы, сжатие станет проблемой

Кароче, тупо найти тот самый минимум при котором уже нужно сжатие "без потерь с обеих сторон".

[Stilet]

Хм... Идея заслуживает внимания. Плюс к этому мне не обязательно сжимать 9-м уровнем же... Это ведь текст.
А браузер сам догадается какой уровень сжатия используется?
Параметр deflate за что отвечает если не секрет?

[Человек_Борща]

Хм... Идея заслуживает внимания. Плюс к этому мне не обязательно сжимать 9-м уровнем же... Это ведь текст.

Вот набросал немного кода...
Определяет размер данных необходимых для достижения потери n% в весе нормального трафика.

Блок текста в 512 байт сжимается в 26 байт и таким образом уровень сжатия 94%

Deflate - можно прировнять к GZIP. Думаю это аппендикс, для старья т.к. gzip в себе содержит реализацию deflate.

А браузер сам догадается какой уровень сжатия используется?

При декомпрессии уровень сжатия берется из шапки файла(потока), который был туда записан при сжатии. Другими словами,
Winrar у вас не спрашивает, с каким уровнем был сжат архив X =).

А Accept-encoding клиент говорит серверу, о каких методах возможного кодирования приходящего трафика знает клиент и соответственно сможет правильно декодировать его.

Я обычно указываю только GZIP.

Сейчас дописываю свой навес над THTTPSend, как раз туда эту идею в самый раз....