[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ftpapi] Best Practice When the Content Type of a Response Is Unknown



Thank you, Scott,

it’s funny but translating back and forth between ISO-8859-1 and EBCDIC works fine here with binary data. Nonetheless I am aware that it is dangerous and unreliable -- at the latest when a change to unicode will be made. That’s why I want to get rid of it.

Speaking of saving as a file or a string I prefer the latter. I’m not happy with the idea of producing so many files just to delete them.
AFAIK the i5 user profile will grow with each object I will create (and delete) -- there’s an article by Joe Pluta on the topic at mcpressonline.

My program is called when our web server receives a request from a customer, I have to forward the responding xml or pdf document to stdout to return it.
To put it more verbose: A cgi program calls another program that processes the received customer data in order to form another request to a third party web service. The response of that third party will be either pdf or xml. The program keeps a pdf answer untouched, while an xml answer will be modified. Both are then forwarded back to the customer. Till now, I have all data in a string to make passing data from one program to the other easier -- and it prevents mixing data from different requests.

Best regards,
Markus

2017-04-26 18:11 GMT+02:00 Scott Klement <sk@xxxxxxxxxxxxxxxx>:
Hello,

I would not recommend translating the data to EBCDIC, and then later translating it back to iso-8859-1.  "Binary" means that the data isn't text to begin with, so when you translate it to another character set like EBCDIC, there may be values that don't get translated properly.  (EBCDIC does not have code points for all 256 possible byte values.)   Likewise, when you later translate the EBCDIC back to iso-8859-1, it will be translated by what the (expected) EBCDIC characters are, and what their equivalent in iso-8859-1 will be, which might not be the original binary values.

A better solution is to keep the data in binary, and only translate it once you've deduced what the data type is.

If you save the data to a file (vs a string) HTTPAPI will always preserve the binary values of the bytes when writing it to the file.  Given the scenario you described, this is probably ideal -- you don't plan to process the PDF as a string in your program do you?   If the data is XML, then you can point your XML reader to the file to process it.  (Or read it into a variable if desired.) In my opinion, this is probably the best approach for your situation, write it to a file, check the content-type header, and handle processing based on that type.

If for some reason you prefer the data in a string without writing it to a file, this is also possible.  When you call http_setCCSIDs() if you set the first two parameters to the same CCSID, such as http_setCCSIDs(819:819) it will not translate the data.   Therefore, the data will be sent as binary data to your program.    Then, you can use routines like http_xlatedyn() or the system's iconv() API to translate the data after the fact if translation is needed.

-SK

On 4/26/2017 2:58 AM, Scholli Zweitausend wrote:
Hi all,

looking for a /best practice/ I hope someone can help me with her or
his experience:

I have to send a request to a service that answers either with a PDF
file (Content-Type: application/pdf) or with an XML file (Content-Type:
text/xml;charset=ISO-8859-1).

When I receive an XML file, http_req() works fine and correctly translates
ISO-8859-1 to EBCDIC. With PDF, it works likewise -- but translating binary
data from ISO-8859-1 to EBCDIC is not the best idea.

What I’ve already learned: A program can tell HTTPAPI which conversion
tables to use by calling HTTP_setCCSIDs() or
http_setOption('LOCAL-CCSID':0)

But as far as I understand, this is not to do a conversion /after/ the
response has been received.

In the past, I re-converted PDF data to ISO-8859-1 using iconv() when I
had received data from the GSKit API -- yes, it worked, but I think
there must be a better, more reliable solution with HTTPAPI.

So, what should I do if I don’t know the content type of the response at the time I am sending the request?

Thanks for any suggestions,
Markus



--
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://scottklement.com/mailman/listinfo/ftpapi

-- 
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://scottklement.com/mailman/listinfo/ftpapi