[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
-----------------------------------------------------------------------