Jakarta HttpClient POST question

W

Wil Hadden

Hi,

I have a quick and hopefully simaple question.

I have been trying to POST some data to a server, and the NamePairValue info
I have been using has a '@' and '+' in it.

When the POST is done the data is encoded ( urlencoded? ) to their %40
counterparts, but I don't want them to be, I want them
transmistted in ther original form.

Anyone know how to do that?

Thanks in advance
Wil
 
T

Thomas Weidenfeller

Wil said:
When the POST is done the data is encoded ( urlencoded? ) to their %40
counterparts,

Which is standard compliant, RFC1738. I suggest you properly decode the
data.
but I don't want them to be, I want them
transmistted in ther original form.

Which is not standard compliant. And I doubt they will change the
standard, just because you want it.

If Jakarta supports this (I never checked), switch to
multipart/form-data. But then you have to decode MIME in the responses.

/Thomas
 
W

Wil Hadden

Thomas Weidenfeller said:
Which is standard compliant, RFC1738. I suggest you properly decode the
data.


Which is not standard compliant. And I doubt they will change the
standard, just because you want it.

If Jakarta supports this (I never checked), switch to
multipart/form-data. But then you have to decode MIME in the responses.

/Thomas

While you are technically correct that that is the standard I doubt if
whoever wrote the server I am posting to will change their software, just
because I would like them to.
 
W

Wil Hadden

Andy Flowers said:
If that is the case then take a look at the source
(http://jakarta.apache.org/commons/httpclient/downloads.html)

You could then look at how to implement a subclass of PostMethod and can
override the generateRequestBody() function to generate the data in the way
you want.

I had thought I may have to do something like that, but I thought I'd check
that there are no methods to turn on-off encoding.

Thanks for the pointer.

Wil
 
A

Andrea Desole

Thomas said:
Which is standard compliant, RFC1738. I suggest you properly decode the
data.

mmmm, rfc 1738 is also valid for post data?
Which is not standard compliant. And I doubt they will change the
standard, just because you want it.

If Jakarta supports this (I never checked), switch to
multipart/form-data. But then you have to decode MIME in the responses.

i haven't tried it, but maybe the http client in jakarta commons can help:


http://jakarta.apache.org/commons/httpclient/charencodings.html
 
J

John C. Bollinger

Wil said:
While you are technically correct that that is the standard I doubt if
whoever wrote the server I am posting to will change their software, just
because I would like them to.

Perhaps not, but without knowing any particulars I would suggest that
you file a bug report. You might (or might not) be surprised by the
result. If the current implementation is provably nonstandard, and if
that hurts its interoperability, then you may find the developer(s)
responsive.


John Bollinger
(e-mail address removed)
 
T

Thomas Weidenfeller

Andrea said:
mmmm, rfc 1738 is also valid for post data?

If I remember it correctly, the encoding is re-used by simply
referencing that RFC from the HTML specs. It might be perfectly possible
that this application of the encoding it is not mentioned in the RFC
itself (like the Java language spec. doesn't list all usages of the
language :)).

I am to lazy to dig out the HTML specs now, but I am sure you can do
that if you want to be sure.

/Thomas
 
W

Wil Hadden

Andrea Desole said:
i haven't tried it, but maybe the http client in jakarta commons can help:


http://jakarta.apache.org/commons/httpclient/charencodings.html

Yep I've had a look there.

It says that the encoding is dependant on the header Content-Type, but I
suspect that's only on the inbound decoding as I tried changing it on the
POSTto no avail.

From what I see I can specify a charset, but it's hard to know where and
what to change it to.

Wil
 
W

Wil Hadden

John C. Bollinger said:
Perhaps not, but without knowing any particulars I would suggest that
you file a bug report. You might (or might not) be surprised by the
result. If the current implementation is provably nonstandard, and if
that hurts its interoperability, then you may find the developer(s)
responsive.


John Bollinger
(e-mail address removed)

Hmmm, I'll look in to that, but out of interest having been looking in to it
I'd be interested to see if it's possible to do it with HttpClient, more
than anything to learn how to use it properly.

Wil
 
A

Andrea Desole

Yep I've had a look there.

It says that the encoding is dependant on the header Content-Type, but I
suspect that's only on the inbound decoding as I tried changing it on the
POSTto no avail.

From what I see I can specify a charset, but it's hard to know where and
what to change it to.


Yes, I also remember that the encoding is specified in the header, and
it should refer to the content of the body; which means, in the case of
a post, all the data you need is encoded using that encoding. I was
thinking that the package might help to decode it (just an educated
guess, as I said)
Anyway, I find the entire thing pretty strange.
I'm not 100% sure, but the thing should work as follows:

1) in the request you can specify the encoding (this should be done by
the browser)
2) the container gets the request with the encoding information, and it
is able to build the appropriate string.

so, as a result you should get plain text, and not strangely encoded.
Just for curiosity: what browser and application server are you using?
Did you try with different ones?
 
Joined
Jul 1, 2009
Messages
1
Reaction score
0
how to : not to post data encoded in httpclient

import org.apache.commons.httpclient.methods.StringRequestEntity
PostMethod post = new PostMethod(URL);
post.setRequestEntity(
new StringRequestEntity("KEY=@{blah}", null,null)
);

java doc
--snipsnip--
public StringRequestEntity(String content,
String contentType,
String charset)

--snipsnip --

StringRequestEntity is meant to create a new entity with the given content, content type, and charset.

to turn off the encoding, u need to set contentType=null and charset=null as done at the beginning.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top