I am currently testing a Classic Webspeed migration to PASOE using the CompatibilityHandler. This works generally well, but I have run into an issue with setting the Status header, and with location redirects.
To demonstrate the issue I have a classic WebSpeed procedure called 'RedirectTest.w' that was created using the 'CGI Wrapper' template in PDS. I replaced the default process-web-request with the following code:
PROCEDURE process-web-request :
output-http-header ("Location", "http://www.progress.com").
output-content-type ("text/html":U).
END PROCEDURE.
Executing this through WebSpeed Classic in Chrome (and Postman), the following header is returned, and the browser relocates to www.progress.com as expected:
HTTP/1.1 301 OK
Content-Type: text/html; charset=UTF-8,text/html
Location: http://www.progress.com
Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
Date: Wed, 07 Feb 2018 13:27:57 GMT
Content-Length: 146
Now, executing the same procedure through PASOE (using the CompatibilityHandler) returns, and does not redirect:
HTTP/1.1 200
Status Code: 301
Location: http://www.progress.com
X-Frame-Options: SAMEORIGIN
Content-Type: text/html
Transfer-Encoding: chunked
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Wed, 07 Feb 2018 13:29:24 GMT
Notice the difference in the HTTP/1.1 portion of the header. In WebSpeed Classic we are properly getting back a 301, telling the client to do the redirect. In the case of PASOE the return is 200, which tells the client to display the body (which is blank).
I have tried specifically setting the status code adding a first line like:
output-http-header ("Status","302").
and
output-http-header ("Status","302 Redirect").
but PASOE still hands the client back a 200.
I have tried access PASOE through IIS/AJP13, and directly (straight shot to PASOE instance), and the response is the same either way (with some minor header changes).
I have done some research on Tomcat to see if there might be some configuration issue, but I wasn't able to find anything. I didn't see anything in the Knowledgebase either.
I could easily be overlooking something simple. Has anyone run into this? Any help is appreciated as this will block us from migrating old applications to PASOE.
Thanks in advance,
Brian
Thank you Peter. I hope there is a fix available, as this blocks our migration from Classic to PAS OE.
FYI, the 'Location' header value is simple 'www.progress.com' The editor added the anchor tag. Please ignore that.
Thank you Peter. I hope there is a fix available, as this blocks our migration from Classic to PAS OE.
There is an (unreleased for now) fix checked in. If you need a hotfix you should contact tech support.
Peter,
I have a question about this fix (I received the fix yesterday and installed in on a dev server last night).
Previously in WebSpeed we could use the following and a redirect would be sent:
output-http-header ("Status","302").
output-http-header ("Location", "www.progress.com").
After this change, that logic will not work. In order to get the same functionality, the code would need to look like:
output-http-header ("","HTTP/1.1 302 Redirect").
output-http-header ("Location", "www.progress.com").
Is this expected? I didn't see any mention of needing to change code in the release notes.
FYI: To keep the old functionality a change can be made to cgituils.i (output-http-header) to treat a 'Status' header like the 'HTTP/1.1' header. This does cause you to manage your out custom cgiutil.i and merge any future changes manually.
Also, previously if a call to 'set-cookie' was made before the first call to 'output-http-header', Webspeed would somehow handle that. Right now, it appears setting the cookie will cause the HTTP/1.1 200 OK to be sent, and any other 'HTTP/1.1' status sent will cause the server to throw a 500. In this case I'm less concerned as it's mainly older code examples that set the cookie before the header and I see the change as just exposing a poorly formed header that should never have been supported. But it was supported under Classic WebSpeed.