Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 209.85.216.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=gk7+g89gHGCHm5VYo07Nk52ck3++0LoVD7x2J07yoqPKiV9qSSzYtQFqQtqNigVgE8
         R7oSoYNoBIiMqO4O67cr/dmHYUzbtxcugPeJ8O5sC+qfGL15wTqf7q6IeJM9+zO4mEUg
         V5Kze/aihG5yihgw2S5R1EumEFwE8f8fndDFo=
MIME-Version: 1.0
In-Reply-To: <AANLkTi=uExdU0UuvLX1_7=Ufegg6ijcPAmhVARogJRoE@mail.gmail.com>
References: <AANLkTikxvgZo+QC2yGB4WYeyGwCROWyBfm8NpAPxpdGs@mail.gmail.com>
	<1292923044.17188.23.camel@ubuntu>
	<AANLkTi=uExdU0UuvLX1_7=Ufegg6ijcPAmhVARogJRoE@mail.gmail.com>
Date: Tue, 21 Dec 2010 21:40:23 +0000
Message-ID: <AANLkTi=eGFPnKjpg=chQwwUY5LCqiQCfQFu+g5QNB0kz@mail.gmail.com>
Subject: Re: Support for servers that cannot handle Content-Transfer-Encoding:
 8bit
From: sebb <sebbaz@gmail.com>
To: HttpComponents Project <dev@hc.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On 21 December 2010 12:00, sebb <sebbaz@gmail.com> wrote:
> On 21 December 2010 09:17, Oleg Kalnichevski <olegk@apache.org> wrote:
>> On Mon, 2010-12-20 at 17:18 +0000, sebb wrote:
>>> Some JMeter users are reporting problems with Post requests which contain:
>>>
>>> Content-Transfer-Encoding: 8bit
>>>
>>> in mult-part form data.
>>>
>>> It appears that some server code cannot handle the CTE header, and so
>>> users are asking for the header to be optional.
>>>
>>> As far as I can tell, the CTE 8bit header is not strictly necessary
>>> for recipients to be able to process the part.
>>>
>>> The header value defined by the StringBody class.
>>> One way round this for JMeter would be to define a new sub-class and
>>> override the getTransferEncoding() method.
>>>
>>> But it seems to me that potentially other user agents may need to
>>> suppress or change the header, so perhaps the class needs some way to
>>> configure the CTE value?
>>>
>>
>> Have you tried the browser compatibility mode? HttpMime generates only a
>> minimal set of headers (content-type and content-disposition for binary
>> bodies) in this mode.
>
> Ah - I did not know about that.
> I'll try that later.

I assume you are referring to HttpMultipartMode.BROWSER_COMPATIBLE,
which works fine.

So there is no need to override the mime-type or transfer encoding values.

>>> ==
>>>
>>> By the way, the ContentDescriptor#getTransferEncoding() Javadoc says
>>> that the value must not be null, yet
>>> FormBodyPart.generateTransferEncoding() specifically checks for null,
>>> and does not generate the field if the value is null.
>>>
>>> May I correct the Javadoc?
>>>
>>
>> There is no need to ask for a permission. This project is yours as much
>> as it is mine.
>
> Sorry, very badly worded.
>
> What I really meant was - is the Javadoc incorrect, or is the code incorrect?
>
> See also
> https://issues.apache.org/jira/browse/HTTPCLIENT-1037
>
> where there is a similar issue with mimeType.
>
> If the browser compat mode is intended to be used to suppress the
> headers, maybe the Javadoc is correct, and the FormBodyPart code is
> wrong?
>
>> 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