Re: Ability to receive POST response data with no given response content length

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

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
-----------------------------------------------------------------------