Corrupted header in CGI response

[BAndrewsRTC]

I wrote a little web service using Scott's YAJLINTO and YAJLDTAGEN. It works great until the request gets to about 8 array elements, about 6K of JSON. Then every second or third request returns error 500. The QZSRCGI job doesn't log anything, but the HTTP server error log gets the following:
ZSRV_MSG0108: Header from script is not valid. Bad header is ---------------- Start ---------------:
ZSRV_MSG0108: Header from script is not valid. Bad header is EndStruct: File name is
ZSRV_MSG0108: Header from script is not valid. Bad header is 'sell_buy_conv_fact': File name is
ZSRV_MSG0108: Header from script is not valid. Bad header is EndStruct: File name is
ZSRV_MSG0108: Header from script is not valid. Bad header is uyer_number': File name is
ZSRV_MSG0108: Header from script is not valid. Bad header is t: File name is

I don't know what generates the "EndStruct" or "---Start---" text, but the "'sell_buy_conv_fact'" and "uyer_number'" text are bits of the request JSON. So if I understand correctly, it seems like bits of the request are making their way into stdout and corrupting the response headers. Am I getting that right? Any ideas how that could happen?

data-into req %data('*STDIN' :                                      
    'case=convert countprefix=num_ allowextra=yes allowmissing=yes')
              %parser('YAJLINTO');                                  ​
...
data-gen res %data(ResBuffer : 'countprefix=num_')              
         %gen('YAJL/YAJLDTAGEN' : '{"http status": ' + HTTP_Sts +
                                  ', "write to stdout": true}');  ​

[BAndrewsRTC]

I ran HTTP traces of good and bad results. Here's an excerpt from the good one:

getsfunc_BRIGADE: apr_bucket_split - return what we found before the newline.
ap_scan_script_header_err_core: Look for : (colon) in Status: 200
Status line from script 'CGI800I.PGM': 200
getsfunc_BRIGADE()
getsfunc_BRIGADE: apr_bucket_read length = 207, rv = 0
getsfunc_BRIGADE: Look for newline or linefeed character
getsfunc_BRIGADE: Newline found.
getsfunc_BRIGADE: apr_bucket_split - return what we found before the newline.
ap_scan_script_header_err_core: Look for : (colon) in Content-type: application

Here's an excerpt from the bad one, which resulted from exactly the same request.

getsfunc_BRIGADE: apr_bucket_split - return what we found before the newline.
ap_scan_script_header_err_core: Look for : (colon) in Name: 'manufacturer_numb
getsfunc_BRIGADE()
getsfunc_BRIGADE: apr_bucket_read length = 7971, rv = 0
getsfunc_BRIGADE: Look for newline or linefeed character
getsfunc_BRIGADE: Newline found.
getsfunc_BRIGADE: apr_bucket_split - return what we found before the newline.
ap_scan_script_header_err_core: Look for : (colon) in ReportValue: '1384'

The "'manufacturer_numb" is from the request. Somehow that's getting into the response header. Have I somehow introduced a memory leak into stdout?

[JonBoy]

What do your definitions look like ? Particularly ResBuffer? My best guess is that it is too small and corruption is occurring.

[BAndrewsRTC]

What do your definitions look like ? Particularly ResBuffer? My best guess is that it is too small and corruption is occurring.

ResBuffer was 64K. I just increased it to 1MB, no change.

[JonBoy]

Best suggestion then is to post this as an issue on Scott's HTTPAPI forum https://www.scottklement.com/forums/viewforum.php?f=2

See if anyone there has any ideas.

[Scott Klement]

I've never seen anything like this before. Can you tell me how to reproduce it?

[BAndrewsRTC]

I've never seen anything like this before. Can you tell me how to reproduce it?

Hi Scott, sorry I never followed up after sending you the code and the HTTP request sample. Just got back from vacation and updated CGIDEV2 to the latest version, which made no difference.

Is there a way to view the contents of stdout while debugging the program?

[BAndrewsRTC]

Solved. Found the following in my httpd.conf:

SetEnv QIBM_RPG_DATA_INTO_TRACE_PARSER "*STDOUT"

Nuff said.

[MFisher]

Always good when problems are solved and the solution posted as a follow-up for others.