Bruce,
Aren't you going to have the same problem with:
rc = http_xlate(%len(%trimr(val2)): val2: TO_ASCII);
rc = write(fd: %addr(val2): %len(%trimr(val2)));
That you had with the decode? - you could be losing part of the image in the xlate and write statements?
As you mention hopefully that image size tag will provide you with the real image length.
Kind regards
Mark Humpage
Consultant
FUJITSU NEW ZEALAND
P O Box 2640, Christchurch
T +64 3 963 7955 M +64 21 284 5167
mark.humpage@xxxxxxxxxxxxxx <mailto:mark.humpage@xxxxxxxxxxxxxx>
nz.fujitsu.com <https://webmail.infinity.co.nz/exchweb/bin/redir.asp?URL=http://nz.fujitsu.com>
________________________________
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx on behalf of Bruce Reynolds
Sent: Wed 7/01/2009 10:58 a.m.
To: 'HTTPAPI and FTPAPI Projects'
Subject: RE: Looking for best option
Hi Scott,
THE <BASE64DATA> tag is not encoded. When I view the data returned for the
GetImageDataResult tag it has <BASE64DATA> rather than <BASE64DATA>
which surprised me that the parser didn't parse it out.
Right now I am just trying to get a good image so the 64k is not a problem.
Once I get everything working I will use the HTTP_XmlReturnPtr() and add
error logic as you suggest.
I changed val2 to be a fixed length for now and below are the changes to the
procedure. I added a scan for x'0D' and x'25' and put the program into
debug for testing and I didn't find any.
D val2 s 32766A
/free
if name = 'GetImageDataResult';
// parser is not breaking out the BASE64DATA tag but it is contained
// in GetImageDataResult. Use %scan to extract it for now
i = %scan('<BASE64DATA>':value);
i += 12;
x = %scan('</BASE64DATA>':value);
fd = open( '/tmp/RDMImageresponse.tiff'
: O_CREAT + O_TRUNC + O_WRONLY + O_CCSID
+ O_TEXTDATA + O_TEXT_CREAT
: S_IRUSR + S_IWUSR
: 819
: 0 );
val = %subst(value: i: x - i);
i = %scan(x'0D': val);
i = %scan(x'25': val);
base64_decode(%addr(val)+2: %len(val):
%addr(val2): %size(val2));
rc = http_xlate(%len(%trimr(val2)): val2: TO_ASCII);
rc = write(fd: %addr(val2): %len(%trimr(val2)));
rc = close(fd);
endif;
/end-free
P E
I had overlooked the point you made in (D). There is tag
<IMAGESIZE>8908</IMAGESIZE> which I should be able to use to determine the
output length.
Thanks,
Bruce
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, January 06, 2009 3:00 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: Looking for best option
Hi Bruce,
Apparently your XML document containing the <BASE64DATA> tag (as well as
other tags) is encoded? i.e. if you look at the data in your
httpapi_debug.txt log, you'll see <BASE64DATA> instead of
<BASE64DATA>? Is that right? (I guess I should've known this from your
earlier discussion... I didn't put 2+2 together)
If so, I would suggest that you extract the whole GetDataImageResult tag
to a temporary file, and then parse that temporary file with
http_parse_xml_string() (or XML-INTO or XML-SAX) to get the BASE64DATA
element. Not sure if that'd make a difference or not, but it's the more
"correct" way to do it.
Other possible problems:
a) I see you're not using HTTP_XmlReturnPtr() as I suggested. This
means your entire XML document (the one encoded in the
GetDataImageResult tag) is limited to 64k, including the whole image. I
don't know if that's a problem or not, but personally, I'd be reluctant
to trust that my image would always be that small.
b) You need to make sure that any non-base64 characters (including
spaces, CR, LF, etc) are removed from the string before feeding it into
base64_decode().
c) Your logic for 'val2' is wrong. Since VAL2 is VARYING, you can't
simply pass %addr(VAL2) to base64_decode. Instead, you'll need to do
%len(VAL2) = %size(VAL2) - 2 to set VAL2 to it's maximum length, then
%addr(VAL2)+2 in the 3rd parameter, and %size(VAL2)-2 in the 4th
parameter of base64_decode(). After base64_decode() is complete, the
%len() of VAL2 should be set to the value returned by base64_decode.
d) When you call the write() API, you can't legally use %trim() on VAL2.
Remember, VAL2 is a binary string. It may contain a x'40' (blank)
that's a completely legitimate part of the image. Don't strip that
blank off! It's not text where x'40' means a blank space -- it's an
image, where it could mean something else!
That's what I see wrong off the top of my head...
Bruce Reynolds wrote:
> Hi Scott,
>
> Attached is the source from a test program that makes the image request
and
> decodes it using base64_decode. I've also attached a savf containing the
> output of the same image from Tomkat. Could you take a look and see what
I
> am doing wrong as they are not the same.
>
> The reason I can view tiff images in my browser is because of the
> Alternatiff plugin.
>
> Thanks,
> Bruce
>
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
> Sent: Monday, January 05, 2009 3:19 PM
> To: HTTPAPI and FTPAPI Projects
> Subject: Re: Looking for best option
>
> Bruce Reynolds wrote:
>> From previous email postings I understand that base64 data should not be
>> converted to EBCDIC
>
> Why not? base64_decode() (from BASE64R4) won't understand the data
> unless it's EBCDIC, so I don't understand why you'd say this.
>
> The whole point behind base64 is that you can translate the encoded data
> any way you like. That's the POINT of base64. Feel free to translate
> the encoded data to EBCDIC -- it's the DECODED data that you have to be
> careful with.
>
> Therefore I'd do this:
>
> a) Call http_XmlReturnPtr(*ON)
> b) Call http_url_post_xml().
> c) in your end element handler, check for the BASE64DATA tag.
> d) if BASE64DATA, allocate temporary memory for the output from
> base64_decode().
> e) if BASE64DATA, call base64_decode()
> f) if BASE64DATA, open an IFS file.
> e) if BASE64DATA, write decoded data to IFS.
> f) if BASE64DATA, close file.
> g) if BASE64DATA, deallocate temporary memory.
>
> The result should be your TIFF file.
>
> The other flaw in your logic is that browsers don't usually understand
> TIFF files. You may need to convert them to PNG or JPG first, then send
> THAT to a browser. If that turns out to be an issue, you might look
> into imagemagick to see if it can convert your TIFF to another format.
>
> Make sense? Let me know if you need more info on any of these steps.
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
The information contained in this email is privileged and confidential and
intended for the addressee only. If you are not the intended recipient, you
are asked to respect that confidentiality and not disclose, copy or make use
of its contents. If received in error you are asked to destroy this email
and contact the sender immediately. Your assistance is appreciated.
<<winmail.dat>>
----------------------------------------------------------------------- This is the FTPAPI mailing list. To unsubscribe, please go to: http://www.scottklement.com/mailman/listinfo/ftpapi -----------------------------------------------------------------------