Hello,
Thank you for many, and good suggestions.
I succeeded to emulate the Java client program just now.
CRLF was not concerned.
Our Java server program failed to read multi-byte strings
'cause I failed to encode the strings in my script.
Original data is in EUC-jp and Ja
[EMAIL PROTECTED] wrote:
> Now I understood the way, but I'm failing even now, 'cause
> LWP/HTTP module sends request headers with 'CRLF'.
> But server-side program coded in Java cannot read my request
> with 'CRLF', which I tested with script using socket program
> sending with 'LF' only.
> It is
TECTED]
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of 田口 [EMAIL PROTECTED](J
> Sent: Thursday, May 12, 2005 5:11 PM
> To: Perl-Win32-Users@listserv.ActiveState.com
> Subject: RE: LWP with b
Sorry to be late again, I was occupied with another work.
> Do you have control of the server-side program ? If so,
no.
> When I use
> application/bang-gzip as the content type, it goes out
> in binary (not base64 encoded), so I'm not sure why yours
> is encoding it.
The content-type shouldn't matter. The problem has to be on the receiver's
end. Try using use CGI in the server script, that should decode the posted
data properly.
--
REMEMBER THE WORLD TRADE CENTER ---=< WTC 911 >=--
"...ne cede males"
0100
_
[EMAIL PROTECTED] wrote:
> Sorry to be late...
>
>
>>Try a different content type :
>
>
> I tried it, and ok the body was sent as binary data,
> but the server side pgm semms to expect the Content-Type
> to be the one I said before "'application/bang-gzip'.
Do you have control of the server-s
Sorry to be late...
> Try a different content type :
I tried it, and ok the body was sent as binary data,
but the server side pgm semms to expect the Content-Type
to be the one I said before "'application/bang-gzip'.
Regards,
Hirosi Taguti
[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> Hello,
>
> I have some trouble making a script with LWP.
> I'm writing a client program "wc_client",
> emulating an existing request which sends gzip'ed xml data to
> our server.
> My script "wprint" running on port 80 printed out the request,
> first of which is produc