[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Ability to receive POST response data with no given responsecontent length
Hi Scott,
Thanks so much for the quick reply and straightening me out on some HTTP concepts. Not including the HTTP_API version I'm using was an oversight - it's the latest 1.21 and is being used on v5r4 (our system) and v5r1 (client's system). You were right on with the fact that it wasn't actual content being sent, but was contained in the response headers. Being new to this realm, I wasn't aware such things as the response headers could contain the needed information. The vendor documentation I'm working off of is typical, leaving the user to decipher what is actually needed ;-) I had been working off dump examples, where previous steps had dealt only with actual content, never the response headers and there was no reference to the information being in the header for this particular step.
The 'disable code' suggestion from the vendor and my thought of using the debug file was never really an option, as I figured there was a work around, thus the query to the FTPAPI forum. You were spot on from my general description.
The debug file naming was my 'stupid' question for the day. I believed I had checked the source for the filename parameter, but what I had remembered seeing was actually the CONFIG_H file variable definition. When I went back to the source after your reply, I saw the HTTPAPI_H prototype, slapped my forehead, and slunk down in my chair with embarrassment
I do want to say a big thanks in general for HTTPAPI, Scott. This allowed us to stay in the RPG realm for this project, and has been great tool to work with and learn from. I did my best to use the source code, comments, and the forum, to gain the knowledge needed to accomplish HTTP and HTTPS communication - for the most part, the information is there if you look hard enough (some trial and error helps too!). On top of that, I can't imagine anyone complaining, as it is open source AND (IMHO) has better support than most purchased software.
When I have some time after this project is completed, I want to re-work one of the programs to use POST_XML, as right now we accomplish parsing by scanning the string, which is sufficient for our goals. I had some problems trying to parse the XML string and want to understand that better.
Carl Forshey
Commsoft
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Scott Klement
Sent: Wednesday, November 07, 2007 12:15 AM
To: HTTPAPI and FTPAPI Projects
Subject: Re: Ability to receive POST response data with no given
responsecontent length
Hello Carl,
> The problem encountered is the response contains no 'content length'
> parameter, so the data/password cannot be retrieved (as HTTPI ends up
> with length = 0). The HTTP_DEBUG log clearly shows "RESPONSE:
> abcdefg" after the response header dump, but using URL_POST or
> URL_POST_RAW does not capture the data in the IFS or in a variable.
I assure you, all of the data in the response that's written to the log
is *also* sent to the callback procedure (for http_url_post_raw) or the
IFS stream file (for http_url_post).
The only stuff that you'll find in the debug file that's NOT returned to
your program are the data that's part of the HTTP protocol, such as the
headers in the request chain, response chain, cookies, etc.
The format of HTTP headers is always "keyword: data", which matches your
description perfectly, as you said "REQUEST: abcdefg", which is
precisely in that format. So I suspect what they're actually sending
you isn't actual CONTENT, instead it's a header in the HTTP response
chain. In that situation, it's perfectly acceptable for the
content-length to be zero, since there isn't any actual content.
Assuming that this is really what's happening, and assuming you're
running a reasonably recent version of HTTPAPI (you didn't say what
version) you'll be able to retrieve the header by calling the
HTTP_header() API after your POST has completed.
rc = http_url_post_raw( whatever );
if (rc<>1);
// handle error
endif;
my_data = http_header('REQUEST');
// my_data is now 'abcdefg'
> the only suggestion the programmers came
> back with is possibly turning off the routine that looks for the
> content length" - which I don't consider an option.
You don't have to disable anything. HTTPAPI is designed to work with or
without the content-length. Content-length is only required when using
persistent connections, for normal connections HTTPAPI should work just
fine without it.
> only option I've come up with is to actually use the HTTPPI_DEBUG
> log, copy from stream file to qtemp/temp, read and scan for
> RESPONSE:, and grab the characters proceeding that label.
I *strongly* advise against trying to parse anything out of the debug
log. That's not what the debug log is for!! The data in the debug log
can and will change from version to version, breaking your code. It's
for humans to read *only*, not for programs to read.
Please try my suggestion of calling the http_header() API.
If that doesn't work, it's probably because I don't fully understand the
situation. That's very possible, because although your description of
the situation is very good, I still have a rather fuzzy idea of what the
response is. So if calling http_header() doesn't work, please send me a
copy of your debug file so I can get a more precise notion of what
you're being sent, and I'll help you solve the problem without resorting
to parsing the debug file.
> On that note, it would be nice to be able to over ride the IFS file
> name of HTTPAPI_DEBUG for this and to enable multiple DEBUG logs for
> different users, processes, etc.
That's easy to do, just pass the filename in the 2nd parameter to
http_debug. For example:
http_debug(*ON: '/home/' + %trim(User) + '/httpdebug.txt');
or
http_debug(*ON: '/tmp/httpapi_debug2.txt');
Or whatever you like. The filename will default to
/tmp/httpapi_debug.txt, but *only* if you don't pass the 2nd parameter.
If you pass the 2nd parameter, it'll use the name you give it.
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
The information contained in this electronic mail transmission is intended by Communications Software Consultants, Inc. for the use of the named individual or entity to which it is directed
and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please notify the sender immediately and delete this
message from your system without copying or forwarding it.
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------