Return-Path: 
 <dev-return-18786-apmail-hc-dev-archive=hc.apache.org@hc.apache.org>
Delivered-To: apmail-hc-dev-archive@www.apache.org
Received: (qmail 99970 invoked from network); 9 Apr 2008 19:34:17 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 9 Apr 2008 19:34:17 -0000
Received: (qmail 90255 invoked by uid 500); 9 Apr 2008 19:34:17 -0000
Delivered-To: apmail-hc-dev-archive@hc.apache.org
Received: (qmail 90233 invoked by uid 500); 9 Apr 2008 19:34:17 -0000
Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@hc.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@hc.apache.org>
List-Post: <mailto:dev@hc.apache.org>
List-Id: <dev.hc.apache.org>
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Delivered-To: mailing list dev@hc.apache.org
Received: (qmail 90224 invoked by uid 99); 9 Apr 2008 19:34:17 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Apr 2008 12:34:17 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [217.72.192.234] (HELO fmmailgate03.web.de) (217.72.192.234)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Apr 2008 19:33:35 +0000
Received: from smtp07.web.de (fmsmtp07.dlan.cinetic.de [172.20.5.215])
	by fmmailgate03.web.de (Postfix) with ESMTP id 18E8CD657D10
	for <dev@hc.apache.org>; Wed,  9 Apr 2008 21:33:47 +0200 (CEST)
Received: from [80.218.61.214] (helo=[192.168.1.101])
	by smtp07.web.de with asmtp (TLSv1:AES256-SHA:256)
	(WEB.DE 4.109 #226)
	id 1Jjg3G-0001N4-00
	for dev@hc.apache.org; Wed, 09 Apr 2008 21:33:46 +0200
Message-ID: <47FD1A1A.1090702@web.de>
Date: Wed, 09 Apr 2008 21:33:46 +0200
From: Nicolas <nic.lef@web.de>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: HttpComponents Project <dev@hc.apache.org>
Subject: Re: Bug in Part.java?
References: <47F90B5E.3020800@web.de> <1207654132.10366.15.camel@ubuntu>
In-Reply-To: <1207654132.10366.15.camel@ubuntu>
Content-Type: multipart/alternative;
 boundary="------------070007020005070102060501"
Sender: nic.lef@web.de
X-Sender: nic.lef@web.de
X-Provags-ID: V01U2FsdGVkX19lC4dEbiUpUPnTfN1Zmo/A/THNrAZQhqX3Yp1J
	FBt3S1G7pY0ggHzljK603lqbqmxm/l/g0Zdv2nfXRxoglIP0Cj
	UUK++NI4A=
X-Virus-Checked: Checked by ClamAV on apache.org

--------------070007020005070102060501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Oleg,

I don't think that it is a problem with the server side script as it 
actually works when uploading binary files by using a web browser 
interface...so it's strange that it works when using a browser. The html 
code for the file input is the following:
<form action="/cgi-bin/download/option.cgi?name=add_submit" 
method="post" enctype="multipart/form-data" name="upload_file">
<input type="file" name="F_NAME" style="width:250">
<input type="hidden" id="hname" value="">
<button type="submit" value="upload">

Somehow the server-side script seems the interpret the second CRLF as 
being part of the file...

Greetings,
Nicolas

Oleg Kalnichevski wrote:
> On Sun, 2008-04-06 at 19:41 +0200, Nicolas wrote:
>   
>> Hello everybody,
>>
>> I noticed that when I used the PostMethod and a FilePart in order to 
>> post a binary file to a server, the file was corrupt when it got to the 
>> server. When I compared the file on the server with the original one, I 
>> noticed that the file one the server had some bytes more at its 
>> beginning than the original one. To resolve this problem, I commented 
>> out line 269 in method sendEndOfHeader in Part.java:
>> protected void sendEndOfHeader(OutputStream out) throws IOException {
>>       LOG.trace("enter sendEndOfHeader(OutputStream out)");
>>       out.write(CRLF_BYTES);
>>       // 21.03.08 had to remove the second carriage return/line feed
>>       // in order to work correctly with binary files and QNap...
>>       //out.write(CRLF_BYTES);
>> }
>>
>> Because I don't know whether this is really a bug or a user error of 
>> mine, I post it in the development mailing list...
>>
>> Greetings,
>> Nicolas
>>
>>
>>     
>
> Hi Nicolas
>
> I do not think it is a bug. The first CRLF pair terminates the header,
> whereas the second one separates the part's head from part's content
> body. This is likely to be a problem with the server side script 
>
> Hope this helps
>
> Oleg
>
>   
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>   

--------------070007020005070102060501--