I am using put.client:http to post string to client. I have “ISO-8859-1” in the service parameter. But they are receiving it ast UTF-8. I have tried sending it to myself and do see data as ISO-8859-1.

Is there anything to trace the http transmission? Other thoughts?

Thanks much.

John,

From the builtin services reference:

[quote]
encoding String Optional.
Character set in which the URL data parameters are
encoded (args or table and/or string). Encoding is required to
correctly convert the String object to bytes when generating the URL
for a post. Specify an IANA-registered character set (for example,
ISO-8859-1).
If this variable is null, the default JVM encoding is used. Because
string is used in the body of the post and not used for building the
URL, you do not need to specify encoding for the data parameter
string.
{/quote]

So, if you are passing the data to be transfered over http in the ‘string’ variable the behavior you see is as expected.

Regards,

Koen

Hello John,

Are you passing the data as bytes? if not you should first convert the string to bytes and pass it to http service. We have observed that passing as String and providing the encoding parameter does not help the cause.

-Rajesh Rao

John,

Try using stringToBytes(encoding with ISO-8859-1)and map the bytes to data/bytes in the http transmission they should receive it correctly.

HTH,
RMG

Thanks everyone! We used stringToBytes instead of http to encode and it worked.

John

I am trying to pass bytes over http. At the target side, the message bytes data appear as Node.

How can I grab the data?

rocky,

is the target another IS?if so, you can use the bytesToString to grab the data which will be in the pipeline.

ramesh.

Ramesh,

Ideally, it would be a remote IS. I can’t use byteToString or any other service because the data (byte) received is in “Name” and not “value”.

Example: Source is passing “hello” as byte over http. Target receives that as “Name: hello” and “Value: null” (if you see the “results” dialog box)

Thanks,

Rocky

rocky,

the remote IS service which handles the request should have a node object as input,which you can convert it into string using bytesToString.
try doing it in the above mentioned way and debug the remote service and see what is there in the pipeline.

ramesh.

I have an “object” variable as input at my target side. Again, if you see the results dialog box,

Name: Value
hello: null

Since the value is null, the bytesToString is converting null value.

rocky,

include the string which you want to send, as a field of a document in the sender’s side and map it to data/args of pub.client:http.and at the receiver’s side, the string name which you have used at sender’s side should be the input(not the whole document).

ramesh

Ramesh,

The string transfer over http works just fine. It’s the byte where I am having problem with…

Rocky

Are you properly encoding it when u convert to bytes?
Please make sure of it.

HTH,
RMG

I think I am …This is what I am doing…

Source: stringToBytes (input as string, say the value is “Test” and then convert to bytes)
pub:client:http (in args, I am passing the above bytes)
Target: bytesToString (I get the node as Test and value as null. And this is where the problem is…)

I hope I am clear or I can attach an export for these 2 flow services…

Did you also explictly set the param loadAs=bytes in the http service input?

please check it.

HTH,
RMG

method = post
loadAs = bytes
passing bytes in args/bytes. I also just using data\bytes.

My header section is null. I tried using the conetent-type, doesn’t like it.

I tried the encoding, with some ISO standard, no avail…

If posting xml document set headers/Content-type=text/xml it should take it.

But i bet byte should work same lime you tested with string.

If i have some time i will try to check you package…sorry…

HTH,
RMG

I tried the headers/Content-type=text/xml … no luck (I don’t even get the message node here)…

"But i bet byte should work same lime you tested with string. " — Disagree…I tried it myself…String works fine but Bytes does not…

I am now thinking may be its a wM bug ?

As final option for debugging put a getTransportInfo,savepipelineToFile services in the target service and disable all the further flow later restore the pipeline and check what are the values showing under the transport/http.

HTH,
RMG