On Mon, 2012-02-06 at 19:16 +0100, Mateusz Parzonka wrote:
> I'm developing and testing a little straight-forward client-server 
> application using java (and scala).
> 
> The server is based on com.sun.net.httpserver.HttpServer and allows the 
> upload of files via a basic RESTful interface using POST and PUT operations. 
> The upload operation is restricted using Digest authentication 
> (http://www.ietf.org/rfc/rfc2617.txt) which we implemented by ourselves, is 
> tested and appears to be working properly in browsers, curl and Apache 
> HttpClient.
> 
> The upload client wraps Apache HttpClient 4.1.2 and executes PUT operations 
> over http to upload file entities. The content-type of the file is specified 
> as application/xml in the header and only a single file is uploaded at a time.
> 
> When uploading files of different sizes strange behaviour could be observed:
> - Files with sizes less than 1.076 kByte are uploaded successfully.
> - Files with sizes greater than 1.122 kBytes fail with a 
> java.net.SocketException: Broken pipe.
> 
> (The exact critical size is unknown since I've created files with different 
> sizes manually to approximate the max working size)
> 
> The reason for the broken pipe is, that the client somehow ignored the 
> www-authenticate-response uploading files of that size, as is documented by 
> the server logs. "Ignore" means, that it just send multiple (4) messages 
> containing no authentication header at all. But smaller files work well and 
> the client sends an authentication request with the proper challenge-response 
> correctly immediately after the www-authenticate-response as it should be.
> 

Whenever a server drops connection instead of sending back a response
message with a status code indicating a problem the fault always lies
with the server.  

Oleg

> The upload works in curl with files of all sizes, so no problem there.
> 
> So at this point, one could say: "There is some bug in your client." Okay, I 
> kind of hope so... but I've also tried an open-source java RESTclient 
> (http://code.google.com/p/rest-client/) (also wrapping Apache HttpClient) and 
> it has exactly the same behaviour!
> 
> We tried it using this client over the internet and its also the same as 
> described. So right now, I just hope I've missed to set something important 
> in Apache HttpClient which leads to this erroneous behaviour and the 
> developer of the open-source RESTclient missed it as well... any ideas what 
> it could be would be great! 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to