4

Apache Abdera を使用して Atom マルチパート データをサーバーに POST していますが、特定できない奇妙な問題がいくつかあります。

チャンク転送エンコーディングの問題のように見えますが、確かなことは経験が不十分です。この問題は、送信した要求に必要な 2 つではなく、1 つの 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 クラスのコピーであり、追加のヘッダーがいくつかスローされています (たとえば、上記のスニペットのパッケージングを参照してください)。「預金」引数は、アトム部分と入力ストリームを保持する単なるオブジェクトです。

デバッガーを接続すると、このコード行に問題なく到達しますが、それがネズミ穴に消えて、このエラーが返されます。

ヒントやヒントはありますか?攻撃の角度をかなり使い果たしました。

私にとって際立っている唯一のことは、atom:entry ドキュメントの直後に、「0」だけの改行があることです。これは、チャンク転送エンコーディングのように見え、「終了しました」を表しています。どうやってそこにたどり着いたのか、本当に効果があるのか​​ はわかりません。大変助かりました。

乾杯、

リチャード

4

1 に答える 1

0

孤独0は確かに問題かもしれません。私の情報に基づいていない推測では、 への何らかの呼び出しが原因でflush()あり、バッファ全体が別の HTTP チャンクとして書き込まれます。残念ながら、 が呼び出された時点でflushは、バッファーは既にフラッシュされているため、そのサイズはゼロです。HttpChunkedOutputFilterそのため、空のバッファをフラッシュする必要がないので、 (または呼び出された方法で)教える必要があります。

[更新:]ChunkedOutputStreamクラス、特にflushメソッドにブレークポイントを設定する必要があります。コードを見ただけで問題ないように見えますが、何か見落としている可能性があります。

于 2011-06-05T09:21:15.277 に答える