Проблема Chunked Transfer Encoding с Apache Abdera

Я использую Apache Abdera для POST атома многокомпонентных данных на моем сервере, и у меня возникли странные проблемы, которые я не могу определить.

Похоже, проблема с кодированной передачей, но у меня недостаточно опыта, чтобы быть уверенным. Проблема проявляется в том, что сервер выдает ошибку, указывающую, что отправленный им запрос содержит только одну часть MIME, а не две, как требуется. Я подключил Wireshark к интерфейсу и запечатлел разговор, и все прошло так:

POST /sss/col-uri/2ee98ea1-f9ad-4f01-9b1c-cfa3c4a6dc3c HTTP/1.1
Host: localhost
Expect: 100-continue
Transfer-Encoding: chunked
Content-Type: multipart/related; boundary="1306399868259";type="application/atom+xml;type=entry"

Ответ сервера:

HTTP/1.1 100 Continue

Мой клиент продолжает:

198
--1306399868259
Content-Type: application/atom+xml;type=entry
Content-Disposition: attachment; name="atom"

<entry xmlns="http://www.w3.org/2005/Atom"><title xmlns="http://purl.org/dc/terms/">Richard Woz Ere</title><bibliographicCitation xmlns="http://purl.org/dc/terms/">this is my citation</bibliographicCitation><content type="application/zip" src="cid:48bd9436-e8b6-4f68-aa83-5c88eda52fd4" /></entry>
0

b0e9

--1306399868259
Content-Type: application/zip
Content-Disposition: attachment; name="payload"; filename="example.zip"
Content-ID: <48bd9436-e8b6-4f68-aa83-5c88eda52fd4>
Packaging: http://purl.org/net/sword/package/SimpleZip

И в этот момент сервер отвечает:

HTTP/1.1 400 Bad Request
Date: Thu, 26 May 2011 08:51:08 GMT
Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8l DAV/2 mod_wsgi/3.3 Python/2.6.1
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml

Указывает на ошибку (которая хорошо понятна). Мой сервер продолжает передавать кучу битов, закодированных в base64, в выходной поток, но в то же время сервер не прослушивает, он уже решил, что запрос был ошибочным.

К сожалению, я не отвечаю за уровень HTTP - все это обрабатывает Abdera с использованием Apache httpclient. Мой код, который делает это выглядит так:

client.execute("POST", url.toString(), new SWORDMultipartRequestEntity(deposit), options);

Здесь SWORDMultipartRequestEntity является копией стандартного класса Abdera MultipartRequestEntity с несколькими добавленными дополнительными заголовками (см., Например, Packaging в приведенном выше фрагменте); Аргумент "deposit" - это просто объект, содержащий атомную часть и входной поток.

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

Любые советы или подсказки? Я почти исчерпал свои углы атаки!

Единственное, что выделяется для меня, - это то, что сразу после документа atom:entry, есть новая строка с "0", которая, по-видимому, является кодированной передачей, говорящей "я закончил". Не уверен, как он туда попал, или действительно ли он имеет какой-либо эффект. Помощь высоко ценится.

Ура,

Ричард

1 ответ

Одиночка 0 действительно может быть проблемой. Мое неосведомленное предположение, что это происходит из-за какого-то вызова flush(), который затем записывает весь буфер как другой кусок HTTP. К сожалению, в тот момент, когда flush вызывается, буфер уже был очищен, и поэтому его размер равен нулю. Итак HttpChunkedOutputFilter (или как бы это ни называлось) следует учить, что пустой буфер не нужно очищать.

[обновление:] Вы должны установить точку останова в ChunkedOutputStream класс, особенно flush метод. Я только что посмотрел на его код, и, кажется, все в порядке, но, возможно, я что-то пропустил.

Другие вопросы по тегам