HTTPFramework + oecgi4.php

Hank

SRP Framework 4.0.7 and oecgi4.php
I am a new user to HTTP Frameworks and am having a setup issue.

When running the contacts example, the response header information is being returned the response body as shown below.
Status: 200 OK Access-Control-Allow-Origin: * Content-Type: application/hal+json Content-Length: 7911 {"_embedded":{"contacts":

Digging a little bit, I find that in procedure HTTP_Services, around line 1426, the response header is added to response:
Response = HTTP_Services('GetResponseHeaderFields')
// Now add the response body.
Response := Body

oecgi4p.php attempts to extract this information from the response and add it to the header.
# extract header information
$header = explode($LF.$LF, $response, 2);
if(isset($header[1])) {
....
}

isset($header[1]) is false$ in the php script, thus the header information is left in the message body.

Is this php issue or http framework issue or am I incorrect in my troubleshooting?

DonBakke

I believe this is a PHP issue. The HTTP response is always returned as a formatted string which combines the status, response headers, and response body data. The code you referenced from HTTP_Services is simply combining all of the constituent items into the final response.

I suppose it is possible that the formatting of the response body is a bit off, but this code has been working for over 5 years. This makes me suspect the parsing in the PHP module is wrong. If you still suspect the problem is in the formatting of the response I'll take a deeper look. It is possible that OECGI4.exe is more forgiving than OECGI4.php.

Hank

oecgi4p.php uses $LF.$LF as the delimiter between header and body.
HTTP_Services uses CHAR(13):CHAR(10):CHAR(13):CHAR(10).

oecgi4p.php uses $LF as the delimiter between header items
HTTP_Services uses CHAR(13):CHAR(10)

I modified HTTP_Services as shown below. This resolved my issue.
Not sure if this is a Revelation issue.

// Get the response status, all response header fields, and the required addition CR/LF.
Response = HTTP_Services('GetResponseHeaderFields')

**
** hh - modifications start - Feb 25/2020
**
OECGIVersion = HTTP_Services('GetOECGIRequest')
IF OECGIVersion = "VERSION:OECGI4P" then
* use CHAR(10), not CHAR(13):CHAR(10) as delimiter
SWAP CHAR(13):CHAR(10) WITH CHAR(10) IN Response
end
** hh - modifications end

// Now add the response body.
Response:= Body

DonBakke

Every source I've consulted says that CRLF is the proper line break. No CR or LF.

https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html

DonBakke

If you want to stick with your modified HTTP_Services code, I recommend localizing the code to your business app. That way any future updates won't automatically undo your changes.

Hank

I did localize the code to my business app.

I will touch base with Revelation (Bryan) to see if modifying the php script could break our O4W application. I prefer we all use the same solution.

DonBakke

@Hank I am very curious what Bryan says about this. We have other accounts using the PHP version of the OECGI and this is the first time we've had anybody report this issue. You also use RUN_OECGI_REQUEST, correct? I assume that formatted the response in a way that worked?

If you wouldn't mind, please email me a copy of a Request log. I am curious what the Request dynamic array looks like when coming in through OECGI4.php.

Hank

I have not contacted Bryan. I will send you the requested log.

We use OECGI3p.php & RUN_OECGI_REQUEST for most of our o4w sites. The code below worked fine for a different project. For the few sites we've upgrade to OECGGI4.pup, we've had no issues.

* set our O4W response
O4WHtml% = response

* set the response header
pos = DCOUNT(inet_header_names%,@FM) + 1
inet_header_names% = "Pragma"
inet_header_values% = "no-cache"
pos+= 1
inet_header_names% = "Cache-Control"
inet_header_values% = "no-cache, no-store, must-revalidate"

Hank

Happy to report that version 4.0.8 fixed my issue.
Thank you.