4.0.10

2023-09-04

OECGI 4.0.2 Love

In older versions of the OECGI, if a developer wanted to capture the values of request headers that were not automatically included in the Request array, a comma delimited list of these headers needed to be entered into the Registry AdditionalValues string. As of OECGI 4.0.2, an asterisk character (*) can be entered instead. This puts all request headers into the Request array. All relevant services within the HTTP_Services module have been updated to be backwards and forward compatible.

Baking More Cookies

In v4.0.7 we provided a GetCookies and a GetCookie service in the HTTPClient_Services module. This was all well and good when handling API requests to other servers, but what about those cookies that were returned to your own APIs? Worry no more because we now have a GetCookies and GetCookie service in the HTTP_Services module to make it much easier to eat those tasty morsels.

What About Blob?

Sending a binary object to another server via a HTTP request doesn't always work. We have added a new argument, ResponseIsBinary, to the SendHTTPRequest service (a member of the HTTPClient_Services module) to force the a "blob" datatype. Note, this requires SRP Utilities 2.2.6 or higher.

4.0.9

2020-07-08

IP Banning

As a compliment to the existing Whitelisted IPs feature we now offer an option to Banned IPs:

Image Added

4.0.8

2020-03-04

OECGI4.php Love

Perhaps you don't know this, but Revelation Software provides two plug-ins for HTTP connectivity. The original and most likely used is OECGI4.exe (or OECGI3.exe for older systems). This is obviously designed for Windows web servers. The other version is OECGI4.php (and there is also an OECGI3.php). This version would be the plug-in of choice for non-Windows (usually Linux) based web servers. We installed the PHP version several years ago on a few sites and experienced no issues with it. However, a customer recently brought to our attention that their HTTP responses were coming back with the headers appearing with the body. Not good! Upon review and with some insight from the ever helpful Bryan Shumsky, we discovered that the PHP plug-in expects the response headers to be separated from the body with LF as the delimiter. The HTTP Framework has been using CR/LF as the delimiter all this time. There is a reason we use CR/LF delimiters...because this is what the HTTP specification requires. What we didn't know was that the PHP plug-in parses our response (expecting LF delimiters) and then builds a property response using PHP functions. Since we were using CR/LF delimiters, the parsing logic failed and kept the header and the body together. This isn't an issue for OECGI4.exe because it basically passes through the response "as is". Did you get all that? TL;DR: The HTTP Framework now checks to see if the EXE or PHP plug-in is being used and sends back the response using the correct delimiters.

4.0.7

2020-02-27

C is for Cookie, That's Good Enough For Me

...

• SetCookie (a member of the HTTP_Services module) - Adds a Set-Cookie header to the response using the indicated Name. The cookie's value and optional attributes will automatically be included as indicated by each argument.
• GetCookies (a member of the HTTPClient_Services module) - Returns all cookie strings from the response headers.
• GetCookie (a member of the HTTPClient_Services module) - Returns the value for the indicated cookie name.

4.0.6

2020-02-04

FrameWorks Friendlier

The SRP HTTP Framework has always been included with the full SRP FrameWorks package. However, the core forms (e.g., HTTP Framework Setup, Web Accounts, and HTTP Logs) were never designed with the intent of running in parallel with the main SRP FrameWorks MDI Frame. A client reported to us that after running our SRP HTTP Framework forms, their main MDI Frame stopped responding to clicks in the Ribbon control. We identified the problem being related to a memory cache conflict. SRP HTTP Framework now uses its own cache and so the two systems are playing nicely with each other again.

...