2011-05-26 17 views
4

Apache Abderaを使用して、サーバーに原子マルチパートデータをPOSTしていて、私がピン止めできない奇妙な問題が発生しています。Apache Abderaのチャンク転送エンコーディングの問題

チャンク転送のエンコードに問題があるようですが、確かに十分な経験がありません。この問題は、サーバーが、送信した要求に必要な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" 

サーバの応答:

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 100 Continue 

私のクライアントは継続サーバーは次のように応答します。

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層を担当していません - これはすべて、Apache httpclientを使用してAbderaによって処理されます。私のコードがこのように見えるんこと:ここで

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

、SWORDMultipartRequestEntityは(例えば、上記のスニペットの包装を参照)に投げいくつかの余分なヘッダとともに、標準アブデラMultipartRequestEntityクラスのコピーです。 "deposit"引数は、単に原子部分と入力ストリームを保持するオブジェクトです。

デバッガを接続すると、このコード行がうまくいき、ラットの穴に消えてからこのエラーが戻されます。

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

私にとって目立つ唯一のことは、atom:entryドキュメントの直後に、 "0"が入った改行があることです。これはチャンクされた転送エンコーディングのように見えます。どのようにそこに着いたか、それとも本当に効果があるかはわかりません。大いに感謝します。

乾杯、

リチャード

答えて

0

孤独0は確かに問題がある可能性があります。私の知らない推測では、それはflush()への呼び出しの結果であり、バッファ全体を別のHTTPチャンクとして書き込みます。残念ながら、flushが呼び出された時点で、バッファはすでにフラッシュされていたため、そのサイズはゼロです。だから、HttpChunkedOutputFilter(または呼び出される)は、空のバッファをフラッシュする必要がないということを教えるべきです。

[更新:] ChunkedOutputStreamクラス、特にflushメソッドでブレークポイントを設定する必要があります。私はちょうどそのコードを見て、それは大丈夫と思われるが、多分私は何かを逃した。

関連する問題