Mailing-List: contact httpclient-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <4580551D.4010805@dubioso.net>
Date: Wed, 13 Dec 2006 20:31:41 +0100
From: Roland Weber <http-async@dubioso.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.0.8) Gecko/20061110 SeaMonkey/1.0.6
MIME-Version: 1.0
To: HttpClient User Discussion <httpclient-user@jakarta.apache.org>
Subject: Re: multipart post parameters?
References: <457F63DC.70006@syncadd.com>
 <598ad5b50612130643n1d18243ek4d647c989ac872a2@mail.gmail.com>
 <20061213191308.241810@gmx.net>
In-Reply-To: <20061213191308.241810@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hello Bastian,

>     FilePart   fPart = new FilePart(file.getName(), file);
>     StringPart sPart = new StringPart("MESSAGE",  "UPLOAD");
>     Part[] parts = {sPart, fPart};
> 
>     postMethod.setRequestEntity(
>         new MultipartRequestEntity(parts, postMethod.getParams()));
> 
> The servlet use org.apache.commons.fileupload to parse the files.
> The usual way to get a message is not working with StringPart anymore
> 
>     request.getParameter("MESSAGE");
> 
> I only found a solution like
> 
>     if(reqeust.getContenetType().equals( "multipart/form-data"))
>         // parse all form data from the upload and get the message

That is correct. If you send multipart form data, you need
to get the parameter values from the parsed multipart data.
If the Servlet API would support multipart form data, the
audience for commons-fileupload would be smaller, I guess :-)

There is one trick which you can _only_ use if the HttpClient
application is and will be the only client for your servlet.
In that case, you can send the string parameter as a query
string in the URL and use a FileRequestEntity instead of a
multipart request entity. Then you don't need fileupload on
the server, but the format is not compatible with browsers.

> some logs without setting anything 

These look fine.

> if I am add setContentChuck(true)it is a bit better

These look fine, too. The only difference is that chunked
encoding will buffer the data on the client side and send
it out in bigger chunks. Hence you get fewer log messages.

> maybe there is a better way to transfer a message to let the
> server know an upload is comming? I am new in this stuff.

What about encoding it in the URL?
http://my.server.name/path/to/servlet/upload

cheers,
  Roland


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org