OK, I may have spoken a little too quickly.  The C-T-E headers are no
longer being sent as part of the parameter values, however, I still have
a carriage return/linefeed at the beginning of each value which is
preventing the user name and password from passing validation.

Trudy Little
Principal Software Engineer - NetDirector
Florida Default Law Group, PL
(813) 342-2200 ext 3142

DISCLAIMER : The information contained in this mail is attorney
privileged and confidential. It is intended only for the use of the
individual or entity named above. If the reader of this message is not
the intended recipient you are hereby notified that any dissemination
distribution or copy of this communication is strictly prohibited. If
you have received this communication in error please notify us
immediately by replying to this email address and then deleting it from
your database


-----Original Message-----
From: Roland Weber [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 17, 2005 1:29 AM
To: HttpClient User Discussion
Subject: Re: Having trouble with MultipartRequestEntity

Hi Trudy,

> I am attempting to use the MultipartRequestEntity to upload a file and
> some additional parameters via HTTP to a client.  The process works
fine

How do you upload to a *client*? HttpClient is the client, the other
side
of the communication needs to be an HTTP server. HTTP is not a
peer-2-peer
protocol where clients can communicate with eachother.

> if I am sending to another Java client, but I am getting some
additional
> text on all the string parameters when sending to non-Java clients
(ASP,
> Perl etc).  I am getting "Content-Transfer-Encoding: 8bit" appended to
> the beginning of each parameter value.  I have confirmed that this
does

That part header is specified by RFC 1521. I assume that your ASP, Perl
and other environments just don't implement that standard (correctly),
while the Java environment does.

> not happen if I submit the file using a standard HTTP page.  The
problem
> also does not occur if I am just using the PostMethod without sending
> file data.  I am using the latest release of HTTPClient.

That's strange, since the StringPart use Content-Transfer-Encoding:
8bit,
while the file parts use C-T-E: binary by default. Maybe your non-Java
environments can't handle different C-T-Es in a single request?

Try PartBase.setTransferEncoding(null) on the string and file parts.
This
should prevent the C-T-E headers from being sent.

hope that helps,
  Roland


---------------------------------------------------------------------
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]

Reply via email to