hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Support for servers that cannot handle Content-Transfer-Encoding: 8bit
Date Tue, 21 Dec 2010 09:17:24 GMT
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.

> ==
> 
> 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. 

Oleg



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message