Rick Strahl's FoxPro Weblog

Web Connection 8.5 Release Post

(Rick Strahl) — Mon, 25 May 2026 07:59:15 GMT

I've released Web Connection 8.5 which is a minor maintenance release of the FoxPro Web and Service Development framework. It's been a while since the last release, so there are quite a few items on the update list, but most of them fairly minor and have no impact on existing behavior.

One Potential Breaking Change

There's is one potentially breaking change related to how default passwords and authentication are handled in wwProcess and wwUserSecurity Authentication. Specifically, this update by default enforces case sensitivity in passwords, which previously it was not. More info below.

Changes

Here are the updated changes in Web Connection 8.5 broken out into some additional detail. As always you can look at the quick overview in the Web Connection Changelog:

Web Connection Changelog

Server Framework Changes

Update New Project Template for CORS Domain Logic

CORS rules have gotten more strict in browsers recently, with certain browsers disallowing the catch-all Access-Control-Allow-Origin: * rule. Previous versions of Web Connection used the * value by default to allow all traffic through by default and left customization to you.

CORS is used by client side Web browser applications typically using JavaScript that use the browser's Http client via the fetch() function or the old XmlHttpRequest object. The problem with * is that recent changes in Web Browser security restrictions do not allow this value longer as a catch-all value. Using that header breaks with an Http 401 Unauthorized result in the browser.

The updated CORS configuration fixes this by explicitly specifying the caller's domain, which has the same effect but requires a little bit of extra code.

Web Connection creates a default CORS implementation as part of the New Project Wizard, which is now updated to look like this:

*** in YourProcess::OnProcessInit()
lcOrigin = Request.GetOrigin()

IF !EMPTY(lcOrigin) 
***    *** Optional - validate origin against a domain list (you implement)
***    IF !THIS.CheckForValidOrigin(lcOrigin)
***       Response.Status = "403 Forbidden"
***       RETURN .F.
***    ENDIF 

	*** Allow all domains IP addresses effectively 
	Response.AppendHeader("Access-Control-Allow-Origin", lcOrigin)  
	Response.AppendHeader("Access-Control-Allow-Methods","POST, GET, DELETE, PUT, OPTIONS")	
	
	lcRequestHeaders = Request.GetExtraHeader("Access-Control-Request-Headers")
	if EMPTY(lcRequestHeaders)
	  lcRequestHeaders = "Content-Type, Authorization" && ,Cookie if you use cookie auth!
	endif
	Response.AppendHeader("Access-Control-Allow-Headers", lcRequestHeaders)
	Response.AppendHeader("Access-Control-Allow-Credentials","true")
ENDIF

lcVerb = Request.GetHttpVerb()
IF (lcVerb == "OPTIONS")
    Response.Status = "204 No Content"
	RETURN .F.  && Stop Processing
ENDIF

Notice that rather than:

Response.AppendHeader("Access-Control-Allow-Origin", "*")

the code now uses the original user's origin domain:

Response.AppendHeader("Access-Control-Allow-Origin", lcOrigin)

There's also a new Request.GetOrigin() method that makes it easier to retrieve HTTP_ORIGIN header.

There's also an updated topic in the documentation that describes the CORS setup for those of you that need to add or update it in existing applications:

Adding CORS Support to a REST Service

Update wwProcess Error Handling to catch nested Errors in Error Handling

One long-standing issue in Web Connection has been nested error handling. Specifically the scenario where an error occurs during error handling could result in an empty response being sent back to the client from the server. The failure also would fail and not fire the rest of the error pipeline, often resulting in really hard to track down errors.

In this release I updated the Web Connection process error handler to detect and better handle errors that occur during error handling. If your code fails during error handling (like say a database error during error logging) that second error is now captured and logged and a generic error page is displayed. This fixes the scenario where you get a blank page result, due to these nested errors which were difficult to debug or pinpoint.

In essence the default error handle is now wrapped in a secondary try/catch/finally loop so that any response through the default error handler will now always produce some sort of output.

You're on your Own if you override wwProcess::OnError

Last resort error handling runs through wwProcess::OnError which can - and frankly should be - overriden in applications. If you override you become responsible for the error returns so make sure you follow the base class' structure for exception handling.

wwRestProcess::OnJsonError Handler

On a related note REST services now get a new OnJsonError method which allows you to intercept REST service errors so you can easily log failures.

Unlike the page OnError() handler, this handler method doesn't generate any output - it only provides a mechanism for capturing the error and potentially logging it. If you want to look at generated output, and based on the headers do error management of some sort you can do so in the wwRestProcess::OnAfterCallMethod() which provides you the generated output as input.

Removed Case Insensitivity from wwUserSecurity Password Checking

So here's the potentially Breaking Change:

I changed the behavior of base authentication in default wwUserSecurity::Authenticate() - which also affects wwProcess::OnAuthenticateUser() - by removing the LOWER() case conversion on the input password to be lower case.

The reason for this is is that modern security often requires and generates mixed case passwords and forcing case insensitivity lowers the password's strength. This affects the password behavior of the built-in wwUserSecurity security process in Web Connection, which you can override with your own wwUserSecurity.Authenticate() method as you see fit.

However, the default implementation is now case sensitive which might break existing users who were expecting to use non-case sensitive passwords. Web Connection's default implementation didn't provide a mechanism to enter passwords natively other than direct entering into the DB, so how passwords are stored was always up to you. If you need to maintain password lower casing there are a few ways to do this:

Force all Passwords to lower
You can force all passwords in the DB to lower case and then force the user's input to lower case. This is a quick fix if you don't want to do any other code changes.
Subclass wwUserSecurity::Authenticate()
You can always subclass the wwUserSecurity class and use a customized version that does the lookup in Authenticate() exactly as you want it to. The default implementation has now removed the lower casing match for the password when doing the lookup but your version can put that lower casing right back in.

Client Framework Changes

Explicit wwDotnetBridge GetField() and SetField() Methods

Several people ran into issues with wwDotnetBridge due to a (not so) recent change that removed the ability to for GetProperty() and SetProperty() to also access fields. Although it's really not recommended to use fields instead of Properties for public and external access, some people can't resist 😄

So due to those recent changes, there are now dedicated GetField() and SetField() methods to that explicitly allow you to retrieve field values including private fields.

Note: The original reasoning for field removal from the Property methods was to improve Reflection performance on fewer members to parse.

wwSQL::cDefaultLocalServerName - Configurable `Server=` when not provided

I recently ran into an issue with a local SQL Server installation that did not - for some reason - work with TCP/IP connections. A botched install that didn't have access to the SQL configuration didn't allow access via TCP/IP and no way to set it. As an aside Windows ARM devices may also not work TCP/IP with local SQL server installations.

Long story short because TCP/IP failed the default local server name of server=. that wwSQL uses didn't work.

wwSql automatically injects the server= into the connection string if it's missing and the value that is injected there is now configurable via two separate values:

wwSql::cDefaultLocalServerName Property
WSQL_DEFAULT_LOCALSERVERNAME default Header Value

The default header value in wconnect.h defaults to 127.0.0.1 and is assigned to cDefaultLocalServerName as the default value. The value can be overriden per wwSQL instance or globally in one place.

Again this applies only if a connection string is used that doesn't include a server name like:

loSql.Connect("database=Weblog;integrated security=true; encrypt=false")

This injects the following:

IF ATC("server=",lcConnectString) = 0
	lcConnectString = "server=" + this.cDefaultLocalServerName + ";" + lcConnectString
ENDIF

with:

*-- The default local server name used when omitted in connection string
cDefaultLocalServerName = WWSQL_DEFAULT_LOCALSERVERNAME

Effectively this allows you to set specific protocols like lpc:. or np:127.0.0.1 or tcp:127.0.0.1,1434 when no explicit connection string is passed. The wconnect.h value allows for a global change in one place without having to assign the value to each instance.

In the end this change allowed us to make a single change in the wconnect.h header file to get the server to use the lpc:127.0.0.1 connection string, without having to upend the entire application. It's not a common feature, but it is useful in some edge case scenarios like this.

Ideally you should always parameterize your connection strings. In a configuration file (create and use Server.oConfig.cAppConnectionString or similar) or Environment variables or whatever. Never hardcode connection strings or any potentially configurable value if at all possible. Thank me later! 😄

wwFtpClient::AddCertificateFromCertificateStore() and wwFtpClient.AddCertificate()

Added a new methods that can be used to add a certificate from the certificate store or from .pfx files to the connection.

For the .AddCertificateFromCertificateStore() version the certificate has to be installed in the appropriate user or machine certificate store. By default the User Store is used, unless you pass the llUseMachineName option as .T..

Remember that for Web applications, the user account is the impersonated account so in Web apps for Web apps that need to add certificates from the store you probably need to install them into the local machine store.

Store Certificates are selected by their subject which look like this:

CN=example.com, O=Example Corp, OU=IT Department, L=Seattle, S=Washington, C=U

Pass the whole subject or CN= value with the CN= prefix (ie. CN=example.com).

For .AddCertificate() you need to provide a .pfx file. Pfx is a Windows specific format of the PKCS #12 encryption which is produced by most Windows based tools that spit out self-signed certificates (like IIS or the local certificate manager).

Both of the methods that add certificates have to be called before sending any commands over the wwFtpClient connection.

Fix: wwSFtpClient::UploadFile and wwSftpClient::DownloadFile() now preserve File Time

These methods now preserve the uploaded or downloaded file's time stamp on the receiving end when the file is saved.

SFTP natively is a streaming API and doesn't support automatic timestamps, but wwSftpClient now explicit calls the server API to match the client and server dates by default. If you need different dates, you can use the new SetFileTime() method to explicitly change the date.

wwSftpClient::SetFileTime()

Added new method to allow setting the file time of a server file more easily.

Note that UploadFile() and DownloadFile() now preserve file dates by default so there should be less need for this method, but it can be used if you different behavior than our new imposed default of time preservation.

Fix: Implement missing wwSftpClient::GetDirectory()

Added missing GetDirectory() method that returns the currently active SFTP directory name as a string.

Note that to return the files in a directory with its directory and file details, use the ListFiles() method.

Fix: wwHttp Upload File Name Encoding

Fixed an old issue that caused problems with filenames that include extended characters when using nHttpPostMode=2.

In some cases files, would double UTF-8 encode the filename= attribute that the server can use to determine what the file name sent was. The old code also wouldn't preserve filename case, so it was hard to determine expected file names on the server.

This has now been fixed and file names are now properly encoded as provided either by explicit filename or by deducing from the upload filename.

There are a number of documentation updates for the Web Connection (and all other West Wind) documentation - courtesy of Documentation Monster.

The help file now has a toggle for light and dark mode. Not a big thing for most, but some (very vocal) people have been asking for dark most on the documentation. The Web Connection docs continue to default to light mode, but you can now toggle to dark mode on the top right toolbar.

The typography has also been updated with more readable fonts, and sizing of the main panel has been adjusted a bit for various display sizes.

Finally the tree navigation now manages topic positioning better, both when jumping in to specific topic links from outside of the docs site as well as when searching in the topic tree. Tree searches should also be significantly faster now than before.

Web Connection Weblog Facelift

I've migrated the Web Connection Weblog to my main Weblog engine that I also use and have recently updated on my main weblog.

As a result the blog now has a more modern look with all old content migrated into the new engine. All old links now forward to the new blog site.

As with the docs site there are improvements like dark mode, improved typography and better sizing for various mobile and desktop form factors.

The old Web Connection blog site was getting a bit long in the tooth and was a bear to maintain. While the site has been working fine, it was missing important back end features necessary to maintain the blog operations.

The new site has been re-homed at:

https://webconnectionblog.west-wind.com

and all old links into the old site now forward to the new site.

If you run into any dead links, please let me know...

Summary

As I mentioned in the beginning, it's been a while since the last release, so a lot of the small fixes have been building up making this is a bigger release than many of the preceding small releases.

However, none of these updated features and enhancements have any significant impact on existing applications in terms of changes required, with the potential exception of the the password behavior in wwUserSecurity.Authenticate() and by association default wwUserSecurity Authentication in wwProcess.

Until next time...

What is CORS and how to set it up in West Wind Web Connection

(Rick Strahl) — Mon, 04 Aug 2025 00:38:39 GMT

CORS stands for Cross Origin Resource Sharing and it's a security feature that you need to be aware of if you're building any Http based REST services that are called from a Web browser and that are accessed across multiple domains. This applies if you have a front-end Web site that runs on one domain, and a back-end server that lives on another domain (or IP address). CORS typically kicks in when making script based requests from a browser for these cross domain calls.

The protocol is an odd one, in that it's typically enforced only by Web Browsers, and not in play for most other Http clients like say wwHttp or XMLHttpRequest in FoxPro, or HttpClient in .NET unless you explicitly mimic the Origin and Access-Allow-Request headers that the protocol uses.

When a browser makes a cross-origin fetch() or XMLHttpRequest call from script, it sends a request for CORS headers which the server should respond to with it's own set of response headers. The browser then checks the server’s response for specific CORS headers like Access-Control-Allow-Origin and Access-Control-Allow-Headers. If the headers match the requesting origin and other headers, the browser allows the calling JavaScript to access the response. If it doesn't match the browser doesn't expose the response to the calling JavaScript Http client and throws a script error on the request.

The purpose of CORS is to allow the server to tell the Web Browser whether it is allowed access to the requested Url. Although CORS has to be implemented by the server, CORS is really a Web Browser security feature that only is enforced by Web Browsers, but not other Http clients.

For example the server may want to ensure that requests only come from one or two domains (origins) that are allowed to access the service when called from a browser. Note that CORS doesn't verify or authorize requests - it's merely a protocol feature that sends requesting headers that are confirmed by the server for a follow-on or in-flight request to process.

Web Browser Only Protocol but implemented by the Server

It's an odd protocol because it's only used in Web Browsers, and mostly irrelevant for other Http clients. The reason is that the actual CORS 'security' feature - rejecting a request on invalid or missing CORS data - is implemented by the Web Browser Http client. So it's up to the client to provide this logic and in general only Web Browsers implement CORS security. Other Http never send CORS request nor do they process them or restrict access based on them.

CORS doesn't fire on localhost

It's also easy to forget about CORS during development, because CORS doesn't kick in when running same origin requests. If your Web page and REST Service run on the same domain/IP Address, there's no CORS. During development that's very common, while deployed applications often run on separate servers. Also if you're using Http testing tools like West Wind WebSurge or Postman, CORS doesn't automatically kick in unless you explicitly provide the CORS request headers like Origin and any Access-Allow-Request-xxxx headers. Hence it's easy to forget to test CORS use cases while testing REST applications. Make a point of remembering and/or ensuring you set up specific tests in your Http client request testing suite (you are using that with your services, right? 😄)

The CORS Protocol

CORS is implemented at the Http protocol level via Http headers that are passed from client to server, and back to the client.

It works like this:

The client sends an Origin header and potentially several Access-Allow-Request-xxxx headers
This signals that the server should return a CORS response
The CORS response needs to include at minimum:
- The domain that is allowed access (ie. the current domain)
- The Http Verbs that are allowed
- The Http Headers that are allowed
- Whether security (Authorization, Cookies) is allowed

Depending what type of request you're making CORS data is either made via a separate, pre-flight Http OPTIONS request, or via in-flight headers that are part of a 'normal' request flow.

Pre-flight OPTIONS Request

For most POST, PUT, DELETE, PATCH operations browsers send a pre-flight OPTIONS request to the server which requests a CORS header response. In effect this results in two requests being made to the server by the browser: An OPTIONS request for CORS verification, followed by the original full Http request.

The Http OPTIONS request from client requests only the Http headers for the request and the response returned should contain only the Http headers that a server is expected to return for this request, which includes the CORS headers. The response code should return headers, no data and have a result Status Code 204 No Data although 200 OK with no data also works - the browser doesn't really care about the result code or content, only the headers.

Here's what that looks like:

Figure 1 - A pre-flight OPTIONS CORS request

Note that this is an OPTIONS request that was originally triggered by a POST operation that also requires Authentication in this case. Note that the client sets Access-Control-Request headers to specify what operations it wants to perform which the server response needs to include by adding the corresponding Access-Control-Allow headers. Remember these are typically sent by a Web browser making a cross-origin request via script code.

The server has to respond with headers that include the requested origin, headers and methods. If the CORS headers aren't matched the actual request (ie. the POST request in this case) is never fired and the OPTIONS request fails the original POST operation that initiated this sequence at the client (ie. the fetch() or XMLHttpRequest call).

To clarify the full request flow in this example is:

Browser makes a fetch() request with POST and Authentication
Browser fires OPTIONS request
Server responds with valid CORS response
Browser makes the original POST request
Server responds to POST request

In-flight Request

For simple GET and POST requests that don't include authentication, cookie or custom headers, an Origin header is sent without a separate explicit OPTIONS request and only the single original request is sent. Instead the CORS headers are checked as part of the incoming request and your full response needs to include the CORS headers directly.

Figure 2 - An in-flight CORS request adds CORS headers to the normal request and response headers. Origin is the trigger.

Since in-flight requests don't use a separate request to determine whether the request can execute, it only includes an Origin header to validate that the domain is allowed. Everything else is moot, because the request is already in process. POST operations sometimes send the Access-Control-Request-Headers, but it's not required which means you can't just assume to echo back the Headers that were sent - or not add the CORS headers if you decide to not reject the CORS request.

CORS Failure and Success Responses

If the client makes a CORS request and your server code decides it doesn't want to allow the request to process, there are number of ways to do this.

For failures simply return no content with 403 Forbidden, and don't add any of the CORS headers, which effectively fails the CORS request on the client. Any fetch() or XMLHttpRequest call will then fail in JavaScript code.

For a successful OPTIONS response use 204 No Content, make sure to return the CORS response headers and then exit before processing the rest of the request.

For in-flight non-OPTIONS responses, make sure to add the CORS response headers, and continue processing your request as normal. No need to adjust any special Http Response code.

Beware of Access-Control-Allow-Origin: *

In previous versions of Web Connection (and other server frameworks for that matter) the default generated CORS response for 'all origins allowed' was to specify * for the origin value. Although this is a valid value per spec, in recent years several browsers - namely Safari on Mac and iOS - are refusing to accept any * wildcard values for any of the CORS response headers.

For this reason as of Web Connection 8.5 the templates have changed from the old Access-Control-Allow-Origin: * syntax to explicitly retrieving the Origin header and echoing it back in the outgoing header value. The code at the end of this article shows the new approach that works in this more restricted environment.

CORS in Web Connection

Web Connection doesn't have direct support for CORS as part of the low level Web Connection Web Server connectors, so CORS support has to be implemented at the application level. It's an optional feature and typically only needed for REST projects, although in some rare situations you may also need it if you have individual REST requests as part of an HTML application (rare, but it happens).

When you create a new REST project via the New Project Wizard Web Connection automatically adds CORS support into the generated Process class in OnProcessInit(). The code checks for an Origin header and then displays the appropriate CORS response headers, based on the incoming request. This ensures that valid cross-origin requests are properly acknowledged and allowed by the browser.

The semi generic code to do this lives in your Process class in OnProcessInit():

FUNCTION OnProcessInit
LOCAL lcOrigin, lcRequestHeaders, lcVerb

*** Unrelated
Response.Encoding = "UTF8"
Request.lUtf8Encoding = .T.

*** Add CORS headers to allow cross-site access on REST calls for browser access
lcOrigin = Request.ServerVariables("Http_ORIGIN")

IF !EMPTY(lcOrigin) 
	*** Allow all domains IP addresses effectively
	Response.AppendHeader("Access-Control-Allow-Origin", lcOrigin)  
	Response.AppendHeader("Access-Control-Allow-Methods","POST, GET, DELETE, PUT, OPTIONS")	
	
	lcRequestHeaders = Request.GetExtraHeader("Access-Control-Request-Headers")
	if EMPTY(lcRequestHeaders)
	  lcRequestHeaders = "Content-Type, Authorization" && ,Cookie if you use cookie auth!
	endif
	Response.AppendHeader("Access-Control-Allow-Headers", lcRequestHeaders)
	Response.AppendHeader("Access-Control-Allow-Credentials","true")
ENDIF

lcVerb = Request.GetHttpVerb()
IF (lcVerb == "OPTIONS")
    Response.Status = "204 No Content"
	RETURN .F.  && Stop Processing
ENDIF

*** ... other OnProcessInit() code

The code first checks for the Origin client header, which determines whether the request is cross-site and requires the server to return a CORS response. No Origin means no CORS data is required on the request. So local domain access, or access from a non-Web Browser request won't trigger CORS requests.

When a CORS request comes in here are the items required:

Original Origins

Next this code implements the default Origin behavior which returns the origin requested, which effectively allows access to all domains since we're always returning what the client requests.

If you want to allow only certain domains, you can create some sort of lookup function or even a hard code a list of domains to allow. If a CORS request fails you can return a 403 Forbidden status - and not return the CORS headers.

Here's what that looks like:

IF !EMPTY(lcOrigin) 
    IF !THIS.CheckForValidOrigin(lcOrigin)
       Response.Status = "403 Forbidden"
       RETURN .F.
    ENDIF 
    
	Response.AppendHeader("Access-Control-Allow-Origin", lcOrigin)  
    ...
ENDIF

Methods

You need to specify the allowed methods when OPTIONS requests are made. In OPTIONS requests the client will send Access-Control-Request-Methods which you can echo back. Not though that this value is not present in inflight requests so it's better to use a fixed set of Http Verbs that you are planning to use in your project.

Easiest just to return all the methods your app supports, but you could also return the specific verb being requested.

Response.AppendHeader("Access-Control-Allow-Methods","POST, GET, DELETE, PUT, OPTIONS")

Note that in an OPTIONS command you need to include OPTIONS plus Access-Control-Request-Methods rather than just using Request.GetHttpVerb().

Headers

This one is a little tricky since you may not know what headers you need to support for all requests. OPTIONS requests provide an explicit Access-Control_Request-Header value that you can echo back, but again there's no guarantee that this value exists so you want to make sure you have a default value ready using this logic:

lcRequestHeaders = Request.GetExtraHeader("Access-Control-Request-Headers")
IF EMPTY(lcRequestHeaders)
  lcRequestHeaders = "Content-Type, Authorization" && ,Cookie if you use cookie auth or Sessions!
ENDIF

The tricky bit here is that you need to provide all custom headers that you might send. While that may seem easy for individual requests, it's more difficult to figure out exactly what's needed for every request in an application and distill that down to a single set of headers. Hence you'll want to use the requested headers if available. If you have custom headers it'll always trigger an OPTIONS request, so in that case the Allow-Control-Request-Headers should be sent with the incoming request and that's what you should return in your CORS header response.

Allow Credentials

If your app has any authentication you'll want to set this value to true. This is needed if you have Authorization or Cookie headers.

Kind of silly that this is required since the headers should be able to determine whether this is required.

Summary

CORS is a clunky protocol and when you first look at it, it doesn't seem to be very effective at providing any security at all. However, for browsers it is useful in ensuring that errand Web browsers can't spoof requests from an embedded iframe for example. The server can explicitly check valid source domains and refuse to serve requests if the list of client domains is not met. However, that does not negate the problem because non-Web Browser clients can call your server any way they want - including potentially spoofed origin domains.

The good news is that it's easy to implement CORS for your REST services in Web Connection. There's only a little bit of code required, and in can be placed into a single entry point in OnProcessInit() in one place. If you're creating new REST projects, Web Connection automatically provides the CORS code in the generated process class and if you have existing code you can easily copy in the code from this article...

this post created and published with the Markdown Monster Editor

Web Connection 8.4 Release Post

(Rick Strahl) — Wed, 23 Jul 2025 01:32:21 GMT

Hi all,

I've released Web Connection 8.4 which is a minor maintenance release of the FoxPro Web and Service Development framework. The primary reason for this release are several small bug fixes that might be impacting some of you if you are:

Using wwUserSecurity Authentication (especially in Virtual Folders)
You're using Multipart Form Uploads via wwHttp

If that's you and you're using v8.1-8.3, you'll probably want to update to the latest version as soon as possible.

There are also a couple of nice enhancements in wwDotnetBridge, and a new documentation viewer offline application.

Bug Fixes

Let's start with the important bug fixes because they are the main reason for this release.

In the last 8.2-8.3 a regression error was introduced that in certain situations would not properly set the wwUserSecurity related authentication Session cookie. Specifically this can be a problem in scenarios where you're using a non-root virtual folder in your Web application.

I'm not quite sure why this particular error occurred only with virtual folders since Web Connection cookies are always set on the domain root, but for some reason cookies set when running under the virtual in some cases would not be set properly. The issue basically was that a session Id was present but for some reason the session was not recovered and so a new session key gets generated on each check attempt which effectively results in a successful login that lasts only for the current requests. Oddly this only occurs in virtuals and then more likely on nested virtuals (for me it happened in the Web Connection Weblog specifically).

It's fixed now where the code now explicitly generates a new cookie on login rather than checking for an existing cookie to update.

Fix: wwHttp Multipart Form Data Content Type not getting set

This issue is another regression that cropped up from the recent work to support greater than 16mb uploads and downloads. Essentially, the Content Type parameter on AddPostKey() was not being passed through in to the request. It does work for the newly added AddPostFile() but if you're using older code that uses AddPostKey() to upload files the content type was not being appended.

In the process of fixing this bug, I also cleaned up the signature to the AddPostFile() method. The method initially had inherited the same signature as AddPostKey() but there were several parameters that are superfluous for uploading files, so the signature was adjusted for more logical flow.

The change to AddPostKey is a potential breaking change if you were using the method since the order of parameters has changed.

Missing JsonService Variable in wwRestProcess Process Methods

Another regression bug relates to wwRestService and the use of the intrinsic JsonService variable that is passed as a shortcut for THIS.oJsonService into a REST Process method. The error was due a missing PRIVATE scope assignment at the top of the processing pipeline in RouteRequest().

This has been fixed.

New and Improved Features

Not much to report in this update but there are few.

wwDotnetBridge: Unblock all DLLs loaded

The classic .NET Framework still uses Windows Vista Style zoning security by default and so respects the custom blocking attributes that are added to binary files downloaded from the Internet (including files embedded in Zip or 7zip files when unpacked), media devices or from non-local domain drives. Files from those sources get implicitly marked by Windows as 'blocked'.

wwDotnetBridge has for some time explicitly removed blocks on wwDotnetBridge.dll which is the initially loaded Dll that loads the runtime. In most cases that's enough, but I've recently run into cases where other DLLs being loaded were also affected and failed when calling loBridge.LoadAssembly(). For this reason, wwDotnetBridge now also removes blocks from any assembly loaded via LoadAssembly() before loading.

This should improve issues with blocked DLL loading significantly, but you may still run into problems if the DLLs loaded load other DLLs implicitly. In that case you can explicitly load those assemblies using LoadAssembly() (starting with the most deeply nested dependency first), or you can manually unblock files as described in this help topic.

New Offline Documentation Viewer

For years several people here - looking at you Tore - have hounded me to provide offline documentation again as we used some time ago. In the past I created a very large PDF document which was problematic to create as I used Word Automation to import from Html and then Print to Pdf. That process was very brittle and took a really long time to run and often would randomly fail.

Well, recently I switched the documentation over to a new documentation system I've been building called Documentation Monster, which is a Help Builder like system built ontop of my popular Markdown Monster editor.

As part of that tool there's a new option to create a self contained documentation viewer application that can be used to browse the online documentation offline.

Here's what that looks like for Web Connection:

All the functionality of the Web site is available in the offline Viewer so you get all the same docs - offline.

The big benefit from my end is that's easy and fast to build so this documentation is much easier to keep in sync with the online documentation.

The tool produces a self contained EXE that itself is very small. The size of the EXE is determined primarily by the size of the documentation which is embedded inside of the Exe and unpacked when run. That said the Web Connection file is still in the 20mb range zipped due to the huge amount of content and media. The Exe has no dependencies as it runs on the built-in .NET framework.

You can check it out from here:

Download the Web Connection Documentation Offline Viewer

Summary

Overall this is a very small release that's primarily been released for the bug fixes (which have been avaiable for a while in the Experimental Updates Zip file as soon as they were discovered and fixed).

I would recommend updating to the latest version if you are on 8.1-8.3.

Creating and Debugging .NET Assemblies for wwDotnetBridge and Visual FoxPro

(Rick Strahl) — Fri, 23 May 2025 03:49:41 GMT

wwDotnetBridge lets you interface with .NET code directly, but if need to access more than a handful of lines of .NET code from FoxPro, it's a good idea to create a separate dedicated .NET component and call that instead. There are many benefits to easier and more discoverable access to functionality, better performance and support for a few features that don't work well through wwDotnetBridge. In this post I show how to create a .NET component, build and run it, and how debug it as well.

FoxPro Running on a Windows ARM Device

(Rick Strahl) — Thu, 07 Nov 2024 06:42:14 GMT

I recently picked up a Windows ARM 'Co-Pilot' capable laptop and took it for a spin running my typical spread of Windows applications and tools. I also checked out how well it works with FoxPro - here's what I found.

Web Connection 8.1 Release Post

(Rick Strahl) — Mon, 14 Oct 2024 19:29:02 GMT

Web Connection 8.1 is out. This is a small maintenance release, but it does include a few significant updates.

Making Web Connection Work with Response Output Greater than 16mb

(Rick Strahl) — Mon, 30 Sep 2024 22:30:22 GMT

Web Connection in the past has not supported > 16mb direct output via plain string based output, due to FoxPro's 16mb string limit. 16mb is a lot of text and while I generally don't recommend returning that much data as part of non-file request (which does support larger files) it's a feature request that comes up from time to time as people overrun the limit. During last weekend's SW Fox conference I heard about this issue again in a session and decided to address it once and for all and this posts describes the change and how it's implemented.

wwDotnetBridge Revisited: An updated look at FoxPro .NET Interop

(Rick Strahl) — Mon, 23 Sep 2024 04:34:21 GMT

In this very long white paper for the Southwest Fox conference, I discuss the basics of wwDotnetBridge and then demonstrate a variety of functionality with 10 examples. We'll see basic usage, how to wrap classes in FoxPro and .NET, how to use a variety of .NET 3rd party libraries, how to handle .NET events and how to make Task based async calls.

West Wind Web Connection 8.0 Release Notes

(Rick Strahl) — Tue, 25 Jun 2024 21:05:49 GMT

Web Connection 8.0 is here and this is the official release post for this new version.

West Wind Client Tools 8.0 Release Notes

(Rick Strahl) — Thu, 30 May 2024 17:19:04 GMT

West Wind Client Tools 8.0 has released as a major version rollup release. Here's all that's new and fixed.

Rick Strahl's FoxPro Weblog

Web Connection 8.5 Release Post

One Potential Breaking Change

Changes

Server Framework Changes

Update New Project Template for CORS Domain Logic

Update wwProcess Error Handling to catch nested Errors in Error Handling

You're on your Own if you override wwProcess::OnError

wwRestProcess::OnJsonError Handler

Removed Case Insensitivity from wwUserSecurity Password Checking

Client Framework Changes

Explicit wwDotnetBridge GetField() and SetField() Methods

wwSQL::cDefaultLocalServerName - Configurable Server= when not provided

wwFtpClient::AddCertificateFromCertificateStore() and wwFtpClient.AddCertificate()

Fix: wwSFtpClient::UploadFile and wwSftpClient::DownloadFile() now preserve File Time

wwSftpClient::SetFileTime()

Fix: Implement missing wwSftpClient::GetDirectory()

Fix: wwHttp Upload File Name Encoding

Documentation Updates: Dark Mode added, Typography and Navigation Improvements

Web Connection Weblog Facelift

Summary

What is CORS and how to set it up in West Wind Web Connection

Web Browser Only Protocol but implemented by the Server

CORS doesn't fire on localhost

The CORS Protocol

Pre-flight OPTIONS Request

In-flight Request

CORS Failure and Success Responses

Beware of Access-Control-Allow-Origin: *

CORS in Web Connection

Original Origins

Methods

Headers

Allow Credentials

Summary

Web Connection 8.4 Release Post

Bug Fixes

Fix User Authentication Session Cookie Bug

Fix: wwHttp Multipart Form Data Content Type not getting set

Missing JsonService Variable in wwRestProcess Process Methods

New and Improved Features

wwDotnetBridge: Unblock all DLLs loaded

New Offline Documentation Viewer

Summary

Creating and Debugging .NET Assemblies for wwDotnetBridge and Visual FoxPro

FoxPro Running on a Windows ARM Device

Web Connection 8.1 Release Post

Making Web Connection Work with Response Output Greater than 16mb

wwDotnetBridge Revisited: An updated look at FoxPro .NET Interop

West Wind Web Connection 8.0 Release Notes

West Wind Client Tools 8.0 Release Notes

wwSQL::cDefaultLocalServerName - Configurable `Server=` when not provided