Problem with transfer encoding using Apache Abdera

Question

I use Apache Abdera for POST atom multipart data on my server, and I have some strange problems that I cannot fix.

It seems like a problem with encoding with encoding, but I'm not experienced enough to be sure. The problem is that the server throws an error indicating that the request I sent contains only one part of the mime, and not two, as required. I connected Wireshark to the interface and captured the conversation, and it looked like this:

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" 

Server response:

 HTTP/1.1 100 Continue 

My client continues:

 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 

And at this point, the server responds:

 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 

Indication of an error (which is well understood). My server goes to the base64 encoded bitstream stream to the output stream, but at the same time the server is not listening, it already decided that the request was erroneous.

Unfortunately, I am not responsible for the HTTP layer - all this is handled by Abdera using the Apache httpclient. My code that looks like this:

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

Here SWORDMultipartRequestEntity is a copy of the standard Abdera MultipartRequestEntity class with several headers added (see, for example, the packaging in the above fragment); the deposit argument is simply an object containing the atomic part and the input stream.

When connecting the debugger, I get to this line of code, and then it disappears into the rat hole, and then I return this error.

Any clues or hints? I pretty much exhausted my angles of attack!

The only thing that stands out for me is that right after the atom: entry document there is a new line with "0" on it alone, which seems to have been translated into the encoding for the transfer "I'm finished." You do not know how this happened, or it really has some effect. Thank you very much.

Greetings

Richard

Answer 1

A lone 0 can really be a problem. My ignorant hunch is that this is the result of some call to flush() , which then writes the entire buffer as another HTTP fragment. Unfortunately, at the moment flush is called, the buffer has already been flushed, and therefore its size is zero. Thus, you need an HttpChunkedOutputFilter (or, nevertheless, call it) than an empty buffer that does not need to be cleared.

[update:] You must set a breakpoint in the ChunkedOutputStream class, especially the flush method. I just looked at his code and everything seems to be in order, but maybe I missed something.