You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by da...@gmx.net on 2006/11/13 19:02:39 UTC
handle the request entities from server to client ?
Hello,
Is there a little example how I can work with the
RequestEntity classes and a servlet.
I don't know how the data come from a servlet to
the HttpClient.
How will the server wrap the data and how can the
client unwrap it ?
Something like a ResponseEntity.
Thanks,
bastian
--
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: handle the request entities from server to client ?
Posted by Roland Weber <ht...@dubioso.net>.
Hello Bastian,
> The following code worked
> fine, but I am not sure if
> it is a 'best practice'.
It is not. See my comments inline.
> private void requestMessages(
> String[] messages, HttpServletResponse response) {
>
> StringRequestEntity s1;
> OutputStream out;
>
> response.setContentType("application/octet-stream");
application/octet-stream indicates binary data. That doesn't fit
with using a StringRequestEntity. As it seems that you are really
sending strings, consider changing the content type to text/plain.
>
> try {
> // SEPERATOR is a static final String
> s1 = new StringRequestEntity(
> Integer.toString(messages.length) + SEPERATOR);
> out = response.getOutputStream();
> s1.writeRequest(out);
>
> for (int i = 0; i < messages.length; i++) {
>
> s1 = new StringRequestEntity(messages[i] + SEPERATOR);
> out = response.getOutputStream();
> s1.writeRequest(out);
> }
Well, this _seems_ to work. But I really have no idea why you
would want to use the StringRequestEntity with the Servlet API.
Is HttpServletResponse.getWriter() not good enough for you?
Besides, you didn't specify the character encoding to use,
so your code will only work if client and server happen to use
the same platform default encoding. The string concatenations
are superfluous and a waste of processing resources. As is the
creation of intermediate request entities. Change to something
like this:
response.setContentType("text/plain; charset=UTF-8");
Writer w = response.getWriter();
w.write(messages.length);
w.write(SEPERATOR);
for(yadda yadda) {
w.write(messages[i]);
w.write(SEPARATOR);
}
>
> } catch (UnsupportedEncodingException exc1) {
> // ...
>
>
>
>
> ---- client source (CLIENT)----
>
> // ...
> * @return Servlet response as <code>String[]</code>
> */
> private String[] getResponse(PostMethod post) {
>
> InputStream is = null;
> String data = "";
> String[] messages = null;
>
> try {
>
> is = post.getResponseBodyAsStream();
> InputStreamReader isr = new InputStreamReader(is);
> BufferedReader in = new BufferedReader(isr);
>
> String line;
> while ((line = in.readLine()) != null) {
> data = data + line;
> }
Seeing pointless string concatenations like these hurts.
Please investigate the purpose of java.lang.StringBuffer.
It seems that JDK 1.5 has a non-synchronized alternative
which is even faster. By the way, why are you reading in
by lines if you're not writing by lines? And you should
set the character encoding to be used by the reader.
> // SEPERATOR is a static final String
> messages = data.split(SEPERATOR);
>
> } catch (IOException exc) {
> // handle this later
> exc.printStackTrace();
> } finally {
> post.releaseConnection();
> }
>
> if (messages == null) {
> // handle this later, throw exception
> }
>
> return messages;
> }
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: handle the request entities from server to client ?
Posted by Tomm Krause <da...@gmx.net>.
Hello Roland,
Thanks a lot for your answer.
The following code worked
fine, but I am not sure if
it is a 'best practice'.
---- servlet source (SERVER)----
// ...
private void requestMessages(
String[] messages, HttpServletResponse response) {
StringRequestEntity s1;
OutputStream out;
response.setContentType("application/octet-stream");
try {
// SEPERATOR is a static final String
s1 = new StringRequestEntity(
Integer.toString(messages.length) + SEPERATOR);
out = response.getOutputStream();
s1.writeRequest(out);
for (int i = 0; i < messages.length; i++) {
s1 = new StringRequestEntity(messages[i] + SEPERATOR);
out = response.getOutputStream();
s1.writeRequest(out);
}
} catch (UnsupportedEncodingException exc1) {
// ...
---- client source (CLIENT)----
// ...
* @return Servlet response as <code>String[]</code>
*/
private String[] getResponse(PostMethod post) {
InputStream is = null;
String data = "";
String[] messages = null;
try {
is = post.getResponseBodyAsStream();
InputStreamReader isr = new InputStreamReader(is);
BufferedReader in = new BufferedReader(isr);
String line;
while ((line = in.readLine()) != null) {
data = data + line;
}
// SEPERATOR is a static final String
messages = data.split(SEPERATOR);
} catch (IOException exc) {
// handle this later
exc.printStackTrace();
} finally {
post.releaseConnection();
}
if (messages == null) {
// handle this later, throw exception
}
return messages;
}
bastian
> Hello Bastian,
>
> > Is there a little example how I can work with the
> > RequestEntity classes and a servlet.
>
> You can't. RequestEntity in HttpClient 3.x is a client side
> interface which you can't use on the server side. HttpCore
> allows the use of RequestEntity on the server side, but it
> relies on HttpCore communication primitives which are different
> >from the Servlet API.
> You might find something to clarify the usage of the interfaces
> in the test code for HttpClient 3.x and in the sample code for
> HttpCore 4.0 respectively.
>
> > I don't know how the data come from a servlet to
> > the HttpClient.
>
> It is sent over a TCP/IP or SSL connection. The same
> connection over which the request was sent to the server.
>
> > How will the server wrap the data and how can the
> > client unwrap it ?
>
> The server writes it's "wrapping" strategy in the
> Transport-Encoding header. The usual options are "id"
> (no header) and "chunked". HttpClient automatically
> interprets the Transport-Encoding header and decodes the
> chunked encoding if necessary. On the client side, you'll
> get the stream as it is sent by the server. Except if
> there is some proxy inbetween that applies a content
> encoding. If that is the case, the Content-Encoding
> header will tell you what encoding has been applied.
>
> hope that helps,
> Roland
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: handle the request entities from server to client ?
Posted by Roland Weber <RO...@de.ibm.com>.
Hello Bastian,
> Is there a little example how I can work with the
> RequestEntity classes and a servlet.
You can't. RequestEntity in HttpClient 3.x is a client side
interface which you can't use on the server side. HttpCore
allows the use of RequestEntity on the server side, but it
relies on HttpCore communication primitives which are different
from the Servlet API.
You might find something to clarify the usage of the interfaces
in the test code for HttpClient 3.x and in the sample code for
HttpCore 4.0 respectively.
> I don't know how the data come from a servlet to
> the HttpClient.
It is sent over a TCP/IP or SSL connection. The same
connection over which the request was sent to the server.
> How will the server wrap the data and how can the
> client unwrap it ?
The server writes it's "wrapping" strategy in the
Transport-Encoding header. The usual options are "id"
(no header) and "chunked". HttpClient automatically
interprets the Transport-Encoding header and decodes the
chunked encoding if necessary. On the client side, you'll
get the stream as it is sent by the server. Except if
there is some proxy inbetween that applies a content
encoding. If that is the case, the Content-Encoding
header will tell you what encoding has been applied.
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org