Return-Path: 
 <dev-return-18789-apmail-hc-dev-archive=hc.apache.org@hc.apache.org>
Delivered-To: apmail-hc-dev-archive@www.apache.org
Received: (qmail 1182 invoked from network); 10 Apr 2008 18:48:03 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 10 Apr 2008 18:48:03 -0000
Received: (qmail 80593 invoked by uid 500); 10 Apr 2008 18:48:03 -0000
Delivered-To: apmail-hc-dev-archive@hc.apache.org
Received: (qmail 80573 invoked by uid 500); 10 Apr 2008 18:48:03 -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 80564 invoked by uid 99); 10 Apr 2008 18:48:03 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Apr 2008 11:48:03 -0700
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [217.150.250.44] (HELO ok2consulting.nine.ch) (217.150.250.44)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Apr 2008 18:47:20 +0000
Received: by ok2consulting.nine.ch (Postfix, from userid 1002)
	id C3ED51980A1; Thu, 10 Apr 2008 20:47:29 +0200 (CEST)
Received: from [192.168.1.102] (84-75-108-49.dclient.hispeed.ch
 [84.75.108.49])
	by ok2consulting.nine.ch (Postfix) with ESMTP id 68AC319809F
	for <dev@hc.apache.org>; Thu, 10 Apr 2008 20:47:29 +0200 (CEST)
Subject: Re: Bug in Part.java?
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
In-Reply-To: <47FE4D5E.3030606@web.de>
References: <47F90B5E.3020800@web.de> <1207654132.10366.15.camel@ubuntu>
	 <47FD1A1A.1090702@web.de> <1207772510.5736.7.camel@ubuntu>
	 <47FE4D5E.3030606@web.de>
Content-Type: text/plain
Date: Thu, 10 Apr 2008 20:47:24 +0200
Message-Id: <1207853244.7817.9.camel@ubuntu>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on
	ok2consulting.nine.ch
X-Spam-Level: 
X-Virus-Checked: Checked by ClamAV on apache.org
X-Old-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=ham
	version=3.0.3


On Thu, 2008-04-10 at 19:24 +0200, Nicolas wrote:
> Hi Oleg,
> 
> Sorry for my rude answer.

Nicolas, there was nothing rude about it. It was all okay. However,
HttpClient is _not_ a browser, and therefore I do not find very
arguments like 'this works with a browser but does not work with
HttpClient' very convincing. Common browser applications tend be
optimized for compatibility with all sorts of broken CGI scripts out
there, very often at the expense of standards compliance.

According to my interpretation of the MIME specification both CRLF are
required. You are very welcome to double-check HttpClient code for
compliance with the MIME spec. 

Oleg

>  I didn't mean to offend anyone. Probably my 
> low english skills led to some understanding.
> I just wanted to tell you about the problem I had because I thought it 
> could have been a bug; if you think its correct like it is now, this is 
> fine for me.
> It's just strange that it is actually working when using plain html 
> forms to post the files...
> 
> Greetings,
> Nicolas
> 
> Oleg Kalnichevski wrote:
> > On Wed, 2008-04-09 at 21:33 +0200, Nicolas wrote:
> >   
> >> 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...
> >>     
> >
> > Hi Nicolas
> >
> > You are very welcome to disagree. 
> >
> >
> >   
> >> 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...
> >>     
> >
> > Feel free to check the relevant RFCs
> >
> > Oleg
> >
> >   
> >> 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
> >>>
> >>>   
> >>>       
> >
> >
> > ---------------------------------------------------------------------
> > 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