Ручная кодировка gzip для Response CamelMessage (несоответствия длины контента)

Question

Я пытаюсь вручную gzip ответную строку, возвращаемую с помощью Camel/Jetty. Я смоделировал мой код (ниже) от того, что другие пользователи разместили here и here, но мне все еще не повезло. Тело, возвращаемое в FireBug, является мусором (например, «æRPP * J ... и т. Д.). Я пробовал настраивать режимы сброса буфера, base64 - вывод ByteArrayBuffer и все, что я могу подумать, чтобы бросить на него.

Одна интересная вещь, которую я заметил, может быть ключом, это размер байтового массива, который я распечатываю в моем коде ниже (а затем использовать для установки заголовка Content-Length), не соответствует Content-Length заголовок отображается в FireBug. Например, данные, перечисленные как 47 байт, выходят как 62 на другом конце, а 153 байта приводят к длине 176 в FireBug. Разница в размерах байтов несовместима между различными вводами образцов. Любые идеи, что Camel/Jetty делает под обложками, которые вызывают изменение этого числа?

val baos = new ByteArrayOutputStream() 
val gzos = new GZIPOutputStream(baos) 
gzos.write(response_string.getBytes("UTF-8")) 
gzos.flush() 
gzos.close() 
val bts = baos.toByteArray() 
println("SIZE %d".format(bts.size)) 

client ! CamelMessage(bts,Map(Exchange.CONTENT_TYPE->"text/plain; charset=UTF-8", 
           Exchange.CONTENT_ENCODING->"gzip", 
           Exchange.CONTENT_LENGTH->bts.size)) 

Answer 1

Хорошо, так что я вспыхнуло WireShark сравнить мои ответы HTTP на другие ответы GZIP HTTP и удалось выяснить проблему. Для будущих людей, пытающихся это сделать:

Когда вы укажете CONTENT_ENCODING для gzip в объекте CamelMessage(), потребитель автоматически сжимает ответ для вас где-то в пост-обработке. Я не знаю, характерна ли эта особенность для акка-верблюда или его части причала. Итак, в моем исходном коде мой вывод был сжат, а затем снова сжат Jetty. Вот почему мои значения CONTENT_LENGTH возрастали (вы не можете больше сжимать сжатые данные, а затем, вероятно, добавляли еще один слой заголовков gzip).

Вкратце: сжатые данные были повторно сжаты Jetty, затем несжатые в моем браузере возвращают исходные сжатые данные, а не сырую несжатую строку.