This post is intended to describe in a little more detail what is new and what has changed in IntraWeb 15.3. There are tons of exciting new stuff in this release and I want to spend a little more time than the usual “readme” notes, so users can get familiar with all the changes.
I’ll start from the breaking changes.
New property LockedSessionNoContentResponse in ServerController.SessionOptions
Until version 15.2.69 the default behavior of IntraWeb when receiving a new request while the target session was locked (meaning that it’s busy processing another request) was this: The new incoming request is put in a wait state up to LockSessionTimeout milliseconds (the default is 3 minutes). If eventually the session becomes free to process the request during this time, IntraWeb will proceed. On the other hand, if the session is still processing the first request and the timeout expires, IntraWeb will raise an exception ESessionAlreadyLocked which would be shown as an error page in the browser. The result would likely to kill the existing session and force the user to start a new one.
From version 15.3.0 we changed the default behavior, introducing the new property LockedSessionNoContentResponse. The default value is True. Setting it to False will restore the behavior existing in IW 15.2.69. When True, IntraWeb will still raise the ESessionAlreadyLocked – and this exception will be effectively logged by IWExceptionLogger, if active – but instead of being propagated to the browser, this exception will be silently treated and a 204 status code response will be sent to the browser. From the standard we have: The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response content.
The result is that the session will be able to continue as there wasn’t a new request. IntraWeb will log the 204 response in the browser console window as an error, but the users won’t see this unless they open the browser’s Developer tools and inspect the console. We believe that this new behavior provides a better user experience.
Nevertheless, we recommend that application developers continue using the ESessionAlreadyLocked logged by the IWExceptionLogger to identify why they happen and use IntraWeb built-in features to avoid these exceptions. A common case is blocking the UI while a long request is being processed, for example, generating a big report, or processing the request in a background queue.
Two new built-in exception templates
We introduced two new exception templates, which follow the same style of the other built-in exception templates: UnsupportedBrowser and 401.
a) Unsupported browser
Whenever an unsupported browser is detected, this is the error message that will appear to the end users (in this example, I was running Internet Explorer 6 compatibility mode):
The page contains links that will redirect the user to the download page of the major browsers. As usual, users can create their own template and name it as IWUnsupportedBrowser.html and save it into the application’s template folder. The user new template will be used instead.
Error 401 occurs when authentication fails. Until version 15.2.69 IntraWeb used to just write the “authentication fails” string to the response. Now it will respond with 401 code and a page similar to the normal exception handling. This page is also used when authentication fails using the new built-in OAuth classes. As usual, a template named IW401.html can be created by the end user to overwrite the existing one.
jQuery 3.6.4 is the latest available version. It’s not only more secure than prior versions but it is also smaller than version 1.x. The new version is highly compatible with previous versions and only a small number of code relying on jQuery should have any modification. We recommend you to extensively test anything that relies on jQuery. We tested our jQuery-based controls, including IWBootstrap, and everything worked as expected.
Streaming (partial responses)
This new version supports partial responses, or more specifically, 206 Partial Content responses. Partial responses allow the browser to retrieve a huge file splitting it into smaller parts. Each part is retrieved in a separate request. The most notable application for this is video and audio streaming, although it can be used with other types of content. IW 15.3.0 transparently handles partial responses for all “static” content served by IW server, including images, video, audio, compressed files (zip, 7zip, RAR), and everything else that is marked as “static” content in TIWMimeTypes list. We are going to publish a demo showing this in action.
The partial response required us to change the internal packet format (the THttpPacket class) that is used to transfer the request/response information within the IntraWeb application. This doesn’t require any specific action from IW developers, unless you are deploying the IntraWeb application using ASPX project type. In that case, you are required to update the required ASPX binaries. The new ASPX binaries version is 220.127.116.11 and can be found inside IntraWeb installation folder.
Microsoft Azure and Google OAuth 2.0 authentication APIs
IntraWeb now supports, out of the box, MS Azure and Google API OAuth 2.0 authentication. IW developers are able to start using MS or Google login in less than 5 minutes with very little coding. All the authentication sequence – which is kind of complicated – is handled automatically by IntraWeb.
Edit: From version 15.3.6 it’s also possible to use Facebook API OAuth services, via our TIWOAuthAppFacebook class.
For the readers that have no experience with Microsoft or Google authentication in web sites and applications, you will surely recognize the feature in the image below:
It means that you can use Google API or Microsoft Azure services to handle the user authentication on behalf of your application. The users use their Google or Microsoft account to login to your application. The authentication is handled by Google or Microsoft services transparently. You don’t need to worry about encrypting user passwords and storing them in your own database, implement services to reset user password, etc. Everything can be delegated to these APIs.
Internally, IntraWeb uses Indy Http client (wrapped in our own TIWHTTPClient class) to handle all the communication needed. Once the communication is done via HTTPS, OpenSSL DLLs are needed when deploying any IntraWeb application using OAuth authentication. We are considering also an HTTP client implementation based on WinInet, which wouldn’t require OpenSSL DLLs.
Edit: From version 15.3.2 users can also use TIWWinHttpClient class to handle the HTTP/HTTPS communication with OAuth providers and other services. WinHttp client doesn’t require OpenSSL DLLs to be deployed.
We are going to release a new demo and some instructions on how to setup the Azure and/or Google environments to start using OAuth.
New template cache
Every time a form using a template is rendered, IntraWeb needs to process the template file again. It means that the file must be read from the disc, loaded into a stream, parsed and put together with the “live” information. Some parts of this work is now effectively cached by IntraWeb template processor engine meaning that the performance has been severely improved.
It also means that once the template is loaded from the disc, IntraWeb won’t reload it again, unless the application is restarted or the template cache is cleared. The SA application now contains a new action in the Tools menu to reset the template cache:
It has come to our attention that some users found it cumbersome to reset the cache via the menu when fine tuning a “live” template. In the next release we will also introduce a new ServerController property that allows users to disable the cache while debugging.
Edit: From version 15.3.3 it is possible to set ServerController’s property DisableTemplateCacheOnDebug (Default True). When set, the template cache is disabled while the application is being run under Delphi/C++Builder debugger.
New and enhanced controls
We included 3 new controls in this release, TIWImageLoader, TIWDownloadButton and TIWDownloadLink. The most interesting one is the TIWImageLoader. This new control is a TIWCanvas descendant which is able to allow the users to select an image from their disc and load it into an HTML canvas on the browser. The image can then be cropped, downloaded, uploaded to the server, etc.
One notable application for this feature is when the user needs to upload images (photos, documents, etc). We are also going to release a new demo showing the features of this new component. Demo application using IWImageLoader:
We also extended the IWCheckBox. Whoever tried to add some custom style to an existing HTML check box quickly realized that it is much more difficult than they could imagine. For more than a decade, IntraWeb already supported an “enhanced” check box style. Nowadays it doesn’t look “enhanced” any more, but it was kept for compatibility with existing applications (and also nostalgia ;-). We introduced new modern styles with this version, which we believe will fill this gap for modern looking check boxes. Users can also provide their own images (setting the style to stCustomImage and using the OnGetImageFileName event to provide the file name of the checked and unchecked states images)
And last but not least:
New version of our IWCertificateManager
This new version (18.104.22.168) fixes a few minor issues and makes the Let’s Encrypt certificate requests simpler. It implements a check to detect if the challenge file is available (after it has been received from Let’s Encrypt certification server) and will emit a warning if the file can’t be retrieved through an HTTP request.
We hope that you can enjoy this new IntraWeb release!