HTTP GZIP-кодирование с многочастным сообщением

Question

Я пытаюсь отправить gzip ed multipart POST на сервер Tomcat из приложения Java, используя Джерси.Когда составной запрос не сжимается, он работает отлично.Другие типы сжатых POSTS работают нормально, например, отправка одного объекта XML.Я (полагаю) публикация сжатых данных не является стандартом HTTP, но кажется, что Tomcat поддерживает их в некоторой степени.

рабочая несжатая многосоставная запись:

POST /myApp/rest/data HTTP/1.1
Content-Type: multipart/mixed; boundary=Boundary_1_23237284_1331130438482
Cookie: JSESSIONID=XXXXXXXXXXXXXXXXXXXXXXXXX;Version=1;Path=/myApp/
MIME-Version: 1.0
User-Agent: Java/1.6.0_26
Host: localhost:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Transfer-Encoding: chunked

d3
--Boundary_1_23237284_1331130438482
Content-Type: application/octet-stream
Content-Disposition: form-data; filename="uploadFile.war"; modification-date="Wed, 29 Feb 2012 18:01:38 GMT"; size=25343899; name="file"

{binary data here}
--Boundary_1_25179713_1331128929019
Content-Type: application/xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><myXMLEntity>stuff</myXMLEntity>
--Boundary_1_25179713_1331128929019--

Когда я сжимаю ихиспользуя Джерси GZIPContentEncodingFilter(), отправляются следующие заголовки, и я возвращаю HTTP 400 с описанием «неправильного синтаксиса»

POST /myApp/rest/data HTTP/1.1
Content-Type: multipart/mixed
Cookie: JSESSIONID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;Version=1;Path=/myApp/
Accept-Encoding: gzip
Content-Encoding: gzip
User-Agent: Java/1.6.0_26
Host: localhost:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Transfer-Encoding: chunked

{binary data here}

Возможно ли то, что я пытаюсь сделать?Должен ли Content-Type на самом деле читать multipart/x-gzip?Я замечаю, что когда он сжимается, текст границы остается за заголовком Content-Type - это тоже проблема?

Answer 1

Я столкнулся с той же самой проблемой (или чем-то очень похожим) и отследил ее до заголовка Content-Type, пропуская параметр boundary при использовании GZIPContentEncodingFilter.Я смог обойти это, используя MultiPartMediaTypes.createFormData () при настройке типа сущности, которую я отправлял в клиенте Джерси.Это гарантирует, что параметр boundary будет установлен раньше, чем Джерси автоматически установит его, что, по-видимому, слишком поздно при использовании GZIPContentEncodingFilter для сжатия объекта запроса.Существует эквивалентный метод для multipart/mixed.

У меня нет удобной IDE, но что-то похожее на это:

// client is a Jersey Client object
client.resource(uri).entity(multipartFormData, MultiPartMediaTypes.createFormData()).post(ClientResponse.class);

Все это говорит, что это будет работать, только если вашСервер может обрабатывать сжатые GZIP запросы.

Answer 2

IMO, вы не можете сделать это таким образом, потому что сервер и клиент должны договориться о том, как общаться (например, сжатие zip). HTTP разработан как запрос / ответ, и сервер может вернуть то, что может поддерживать клиент. Клиент отправляет запрос: «Привет, сервер, мне нужен этот ресурс, и я поддерживаю gzip, так что ты можешь вернуть gzip, если сможешь». :) Представьте себе ситуацию, когда ваш клиент отправляет на сервер несколько мегабайт в gzip, но сервер не поддерживает это.