On 21 December 2010 12:00, sebb <[email protected]> wrote: > On 21 December 2010 09:17, Oleg Kalnichevski <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
