- Web Connection Web Control Framework
Web Connection 5.0 introduces a new Web Control framework that uses control and objects to represent HTML content. The new framework is capable of using ASP.NET style visual designers like Visual Studio 2005 and the free Visual Web Developer. This is a major addition to Web Connection that provides a much richer programming model to developers, visual designer support and provides an easy way to extend existing functionality of the framework by allowing easy extension with custom and user controls. - Web Connection moved to VFP 8.0 and later codebase
Starting with Version 5.0 Web Connection will only support VFP 8.0 and 9.0 and later. This has allowed removing of some fairly messy bracketing code, and integrate some of the newer VFP 8 and later features, particularily Exception handling which is crucial for the Web Control Framework.
- Server.lDebugMode is now a non compiled flag
Server.lDebugMode which determines whether the server runs in DebugMode or Deployment mode is now a flag that is settable at runtime. The DEBUGMODE WCONNET.H flag has been removed from the core Web Connection engine so switching between debug mode can now be performed at runtime or more commonly via a simple INI file switch. - New Exception based Error system
The Error handling in Web Connection has been replaced with a TRY/CATCH based exception handling mechanism that provides much richer flexibility in error handling. This feature removes the Error method based approach that Web Connection previously used. This change made it possible to move to dynamic DebugMode management as Error Methods are no longer included/excluded depending on the DEBUGMODE flag. Instead TRY/CATCH handlers provide reliable error handling and returning to a stable point of origin when an error occurs. - Overhauled Security System
Web Connection now includes an extensible security system based on the wwUserSecurity class. The class provides basic login capabilities and user management. The class can be used for simple page based authentication with a couple of lines of code and works as a single line wwProcess::Authenticate() validation. The setup is configurable so you can use custom classes and implementations. The Authentication mechanism also carries into the Web Control Framework, which also includes a new wwWebLogin control that can be dropped on a page and provide control level Authentication on a form. - New wwCollection Classes
Web Connection now includes a set of custom collection classes. Classes include wwCollection, wwNameValueCollection and wwStack. The classes are custom because the native FoxPro collection class syntax is backwards, doesn't support case insensitivity and chokes in a variety of scenarios with various standards. The Page framework requires lots of collection support and it's implemented through these classes which use underlying arrays.wwWebAjax Control added
There's new AJAX control that is part of the Web Control Framework that provides very easy AJAX integration into existing applications. The control supports hover window popups from URL content, very easy URL callback support and a simplified Page Method Callback Mechanism that makes it super easy to callback on the current server page and return values using a simple RPC style interface.
- wwCache Enhancements
You can now use wwCache more efficiently on a URL based basis by not specifying a cache key. If you omit the Cache key Web Connection will automatically construct a current request id that consists of the URL plus the querystring. This makes it possible to easily cache the content of the same page based on different page parameter settings. - wwRequest.Params method to retrieve values from Form, QueryString, Session or ViewState
This new function automatically looks in the Forms, QueryString, Session and ViewState collections for a value and returns the one that it finds first. The order used is the order shown here. - wwSession Update
Fix: wwSession has been updated with wider fields to avoid any potential session id duplication in high volume scenarios. Although unlikely before the new wider Session Id value that incorporates a thread ID ensures that there are no duplicate ids generated. - IIS 6 Kernel Caching support
IIS 6 introduces a powerful feature called Kernel caching which provides dynamic requests to cache on the server the same way as static pages do. Web Connection now supports this feature simply by adding Expires and Last-Modified headers. - ValidationErrors Member for wwBusiness
The wwBusiness class now has a oValidationErrors member that can be used to hold validation errors as a collection which is a bit cleaner than the previous string only error. The ValidationErrors collection can also be added to the wwWebPage BindingErrors collection and participate in error display for page errors. - wwPop3 Fixes
There have been a few fixes that deal with reading the content containing delimination characters (.'s specifically). The code has been reworked to try and read the message buffer based on message size rather than parsed reading of the content dynamically.wwUtils.File2Var reads and writes in shared mode
File2Var now always reads in shared mode meaning that files can be accessed at the same time. This might improve performance a little with template reads and the like. For writing there's an optional flag that allows shared writes as well although you should be very careful with this option and only use it in special situations. Unlike STRTOFILE and FILETOSTR(), File2Var doesn't cause a FoxPro error but instead returns a blank or .T. and .F. respectively.
- Logging and Request Security Context
The Web Connection wc.dll now returns a unique GUID and ThreadId for every request which is accessible via Request.ServerVariables("REQUESTID"). wc.dll uses this id to track a request through the ISAPI extension. To ensure 100% that the output you generate goes back to the same user you can add a RequestId HTTP header to your request and the ISAPI DLL will double check that id on return. Should there be any discreprancy whatsoever between the header returned and the ID passed in an error page is displayed. This ensures that data cannot be compromised at any point from within the Web Connection ISAPI environment. This feature has been added to security concerns from several high volume customers who have experienced hardware Web Server problems and this option provides an additional layer of security to ensure that requests are consistent through the request pipeline. Web Connection now adds the Request ID header automatically if you call the default header functionality.
There's also a new logging mode with a LogDetails INI file flag. If set to 1 this flag logs to wcError.txt out at the beginning and end of the request.wwRequest::lUtf8Encoding
Added a flag that allows retrieving all request data in UTF8 format. When set both QueryString and Form variable retrievals are UTF-8 decoded into the current character set (STRCONV(,11)). This is required for any client page that posts data in UTF 8 format - such as any request data encoded using JavaScript encode or encdeUriComponent functions.
- ISAPI DLL Impersonation Changes
Due to changing security environments and in order to simplify the ISAPI security environment for running COM objects, Web Connection has change the way that the ISAPI DLL handles impersonation internally. By default the Web Connection ISAPI DLL (wc.dll) now runs under the Web Servers user account rather than the impersonated user that is the default for ISAPI. For IIS this account typically is SYSTEM. This change greatly simplifies COM configuration and allows Web Connection in most cases to run in COM mode without any additional configuration beyond COM registration with /regserver. The change also mimizes and simplifies the security impact and gives Administrators control over the security environment that the Web Connection application runs under.
The new operation is implemented by default but a new Impersonation switch in wc.ini allows switching back to the old style of Impersonation operation.
- wwCache Enhancements
The wwCache class can now work with a fixed file that can be shared across Web Connection instances. The new optional cFixedFilename property allows specifying a fixed filename that is used to open a FoxPro table as opposed to the default behavior of opening a local cursor. We've also added support for Removal of cache items and cache expiration routines. - wwRequest::FormVarsToObject - No object input required
FormVarsToObject can now work without an input object in VFP 8 and 9. A new object is created with properties for each of the HTML Form variables with string values assigned for each of the values. - PostBufferSize HTML Page key for Post Buffer Oversize errors
There's a new flag for a PostBufferSize in the Html Pages section of wc.ini that allows assigning a custom message to oversized Post Buffers on input. - New Utility routines
There are a handful of new utility routines that have been added to wwUtils. GetXmlDomObject is a factory method for an MSXML object using a predefined Progid defined in WCONNECT.H. GetRegExObject does the same to retrieve an instance of the VBScript RegEx object. CopyObjectProperties does a shallow copy of properties of an object instance to another instance. Note this differs from the CopyObject routine which creates a new object. - Miscellaneous Updates and Fixes
This version update is relatively minor and rolls together a few errata that have come up since the release of 4.65 a couple of weeks ago.There are a few minor bug fixes and a few kinks in the setup routines that have been fixed and updated and supercede the update files posted previously. - wwHTTP::HTTPGet adds a download to file capability
To further reduce the need to use HTTPGetEx() for HTTP access the HttpGet() method now supports a 4th parameter to download HTTP content directly to file. This is useful for downloads of large content so that the output is moved into memory and returned as a string - useful for multi-megabyte downloads. This functionality was one of the last features that had to resort to using HttpGetEx(). HTTPGetEx() still is the low level interface to wwHTTP and HttpGet() delegates to it, but user code is recommended to use the easier to use HTTPGet() method. - Documentation updates
There have been a number of documentation updates to the Setup and Configuration topics. Specifically the 'troubleshooting' sections have gotten a big overhaul with topics rearranged and content adjusted for newer Web Servers. Among them: Troubleshooting Filebased Server Installs, Apache for Windows Manual Configuration, Deploying an application to a live Web Server, Manual COM Server configuration and Manual File Server Configuration. - Improved Support for Apache 2.0 ISAPI
A lot of people have been asking about Apache support and Web Connection now includes a custom Apache Module that works around some issues with the Apache ISAPI implementation. One of the things this module does also is provide Windows Authentication to Apache (optoinally) so it makes Apache behave more like IIS in terms of program driven (Basic) Authentication. The main reason this was done is to make sure that the wc.dll Admin functions can be locked down which otherwise would have been very tricky to setup with Apache script security. - wwGhostScript
The wwPDF classes now support the free GhostScript interpreter to generate PDF files. We've implemented a small wrapper DLL function for GhostScript that is part of wwIPStuff and can quickly and efficiently render PDF output from PostScript files. The functionality of this class will be identical to the wwDistiller class - you still need to install a PostScript Printer to print a PDF file first. Performance of this interface is much more efficient than Distiller. - wwXFRX and a few other updates to wwPDF
The wwPDF class also adds suport for XFRX to compatible PDF generators in Web Connection. XFRX is a VFP based PDF (and several other formats including DOC, XLS, HTML, RTF) generation tool that uses VFP reports natively. The wwPDF documentation has also been udpated to reflect the latest new drivers and a more extensive comparision between the supported drivers. - InstallPrinterDriver Function in wwAPI and Console option
In order to facilitate installation of a Postscript Printer driver that can be used with the wwDistiller and wwGhostScript PDF generation classes there are now a couple of easy ways to install a printer driver. The wwAPI library contains the InstallPrinterDriver function and the CONSOLE.EXE has a new command line option "INSTALLPRINTER" that can be used to perform this task. Useful for installers or quickly configuring a machine via a batch file. - wwResponse.TransmitFile allows sending large Response output
The new TransmitFile method of the Response object allows sending huge output from Web Connection applications without having to read this data into memory. Output can be sent to file which is then sent to the ISAPI DLL directly. DownloadFile has also been updated to use TransmitFile behind the scenes. This simple function makes it much more efficient to serve contents from files to your clients for applications like secured access areas of for pay content etc. This function has lots of implications from allowing large output (larger than 16 megs) to be created in Web Connection to providing lightning fast access to files without passing them through Web Connection. - New wwServer::lUseRegistryForStartupPath property
This new flag allows overriding Web Connection's default behavior of looking in the registry to find the startup path. This behavior is the default and used to allow remote machines to start an application in a specific directory rather than defaulting to the current directory. When set to .F. Web Connection now always starts in the current directory. - wwSQL::ExcuteNonQuery Method
Added a new method for running non-result set returning SQL Statements. Although EXECUTE supported this functionality before these methods have been isolated explicitly to allow for wwADOSql's customized routines that use different mechanisms to retrieve data and run commands. - wwSql improvements and wwADOSQL Class
wwSQL now has a AddParameter method that allows you effectively create parameters on your SQL statements and pass them around - this feature avoid hardcoding SQL parameter values and is a big help in sidestepping SQL Injection issues. wwADOSql is a new class that provides the same functionality as wwSQL but uses ADO. While slower than SQLPassthrough, ADO provides the ability to deal more effectively with Unicode data. This new class requires VFP 8 for basic operations and VFP 9 in order to take advantage of effective Unicode data access. - New Unicode Language Sample Added
We've added a sample that demonstrates how display content in Unicode format from VFP data. Sample demonstrates how to capture and display extended characters for upper character sets like Chinese, Korean and Russian and display multiple languages in the same page by utilizing binary fields to store the Unicode data. - Automated HTTP Headers through wc.dll
Web Connection now feeds standard Web Server headers for every request while running through the ISAPI extension. The ISAPI DLL now adds common Web Server headers as configured in the Web Server configuration. In IIS these include user configurable headers as well as the Web Server name and request date time stamps. The DLL now also adds the Content-Length on every request that doesn't explicitly provide it automatically. As before the DLL also adds a default content type header if none is provided at all. All header creation calls now are routed through the standard ServerSupportFunction() ISAPI API which provides better compatibility with non IIS Web Servers (see Apache support above). - Several enhancements to wwIPStuff's Email handling
wwIPStuff now adds the cExtraHeaders at the top of the email message which means that the extra headers take precedence over any default headers wwIPstuff adds later on. A new AddHeader() method has also been added to make it easier to add custom Headers to emails. This in turn means you can override wwIPStuff's default headers and should alleviate, in most cases, any restrictions on headers used that existed before. wwIPStuff now also handles return receipts with new lReturnReceipt property which sends a receipt to the sender. The cMailServer property now supports port numbers as part of the mail server address (mail.myserver.com:2525) which overrides the nPort property. - Response.ExpandTemplate() now defaults to Request.GetPhysicalPath()
The first parameter of Request.ExpandTemplate and Response.ExpandScript() now defaults to Request.GetPHysicalPath which looks to a file on disk that maps the current URL to the local disk.The physical path is a very common parameter choice and therefore makes a good default value. - wc.dll Updates for handling long Server variables
wc.dll previously used a fixed buffer size for retrieving server variables that conformed to common standards for lengths of various strings returned. However, many applications these days easily overwrite these limits. wc.dll has been adjusted for this so that now values of any length are accepted. This is especially important for Cookie Handling of extremely long cookies or multiple long cookies which could fail in previous versions. - New WWC_EXTENDED_LOGGING_FORMAT #DEFINE in wconnect.h
There's a new flag in wconnect.h that allows specifying additional information to be logged in the Web Connection Log file. The extended format logs POST data and the Browser string in addition to the script name, querystring and IP Address that was previously logged. This is primarily meant for improved debugging features and tracing of spam, or malicious access to the site. By logging POST data you can potentially get a better idea of what people are doing if you know there's a problem. Please be aware though that logging this additional data will result in potentially larger log files, so make sure you frequently adminster the file lest it get too large and fill up your disk. - Installer and Wizards now set directory permissions automatically
The Web Connection Wizards now set permissions on the any of the install directories automatically. Web directories are set with IUSR_ rights and the Web Connection temp directory selected is automatically set with read/write access rights for IUSR_. All permissions are set on private directories. The installer and Wizards now also create a all script maps as local scriptmaps rather than global scriptmaps. This should avoid one of the most frequent 'getting started' SNAFUs in Web Connection. This functionality is provided in the Setup, Create Project and Configure Server Wizard. - Programmatic Server Configuration Docs updated
I've updated the docs for programmatic Server Configuration due to many requests recently. This topic should point people who want to build automated Web Connection installs into the right direction. Web Connection includes all the functionality to fully self install including creating virtuals, script maps, setting directory permissions and registering COM servers and setting DCOM permissions automatically. - Console.exe gets DCOM configuration command line options
You can now execute CONSOLE.EXe with command line options to set DCOM impersonation and permissions for COM Servers. The new DCOMIMPERSONATION and DCOMPERMISSION options let you automate automate this process a bit easier. - wwAPI CreateProcess and CreateProcessEx functions added
We added API level CreateProcess functions that allow more control over executing external processes than the run command. The plain version supports executing another process, waiting for completion, hiding the window. The Ex version adds the ability to redirect output to a file which is very useful for console applications. Provided to reduce the 'flicker' of flashing command windows when running the various Web Connection Administrative routines (SetAcl, DCOMPermissions etc.).
What's new