I need to support a wconnect 4.68 app. However, I already have wconnect 6.10 (c:\wconnect) on my current dev box.

Will the 4.68 app run under the installed 6.10 ? Or should I install 4.68 under it's own folder (i.e. c:\wconnect468)?

I realize the older auto configs programs probably wont work because IIS on machine is version 10, but I figure I can manually set.

Thanks, Doug

Web Connection works great side by side, but you definitely need separate folders. All versions are folder independent except for the samples which want to install to a /wconnect virtual (which you can change). Newer versions make this even easier because you don't have to use IIS locally at all - you can use IIS Express which doesn't share a 'site' but works of folder you specify. Going forward there will be an dev integrated server provided in the box (.NET Core Based) so other than having a .NET Core Runtime installed you won't need anything else.

Older versions are more finicky about where they live, but newer versions (post 6.x and the newer project system) can live anywhere - all you have to do is point it at the right place for where Web Connection is installed during development, so it can find all the library files. The key here is setting the path in your projects so that the right install files are found.

If you're starting a new project, I would recommend running the latest version as it has many improvements with project management and automatic build and configuration features that make it much easier to get a project online. All of this works in older versions too, but it isn't as automated, so more manual work.

+++ Rick ---

I have it (4.68) working in a seperate drive and it's own folder (d:\wconnect468). All is fine, except the HTTP_COOKIE variable is not being passed. So THIS.InitSession(Config.cCookiename,3600,.t.) is creating a new session on each hit.

How do I get the client to pass the http_cookie?

Doug

You might want to delete your wwSession.dbf table. This sounds like a ID field size issue. Make sure you're not sharing that wwSession table between really old and new versions as the field sizes have changed. The very old version used fixed length keys and was comparing based on the field size, while the newer versions use varchar non-padded fields.

If that doesn't work, check in the wwSession.prg code in LocateSession() and see how and why it's failing (look at the value) and also at the ID generation routine.

+++ Rick ---

I deleted the wwsession.dbf. It rebuilt with a different lenght (14 char). It was C(9) before. However, that didn't help.
I Stepped through and found that the request.cservervars does not have the HTTP_COOKIE in it.

So, when Initsession() calls wwrequest.getcookie(), it returns "". Which is passed to IsValidSession() which calls LocateSession() but all pass an empty value, which of course is not found.

Why is the HTTP_COOKIE not in request.cservervars?

Doug

Check the request. The cookie has to be create when a new session is created. Make sure that InitSession() is called or otherwise the Session object and the cookie will never be sent.

Make sure you're not clearing HTTP headers when session cookies are created. Check HTTP requests when a new login/session attachment occurs and see if there's a set-cookie header sent. It should. I don't remember where that happens in Web Connection 4.68 (InitSession() is a good place to start for stepping).

+++ Rick ---

Initsession() is being called.

I checked the request and the output from the Status area.

The set-cookie is being sent in the output (like this): *HTTP/1.1 200 OK Content-type: text/html Set-Cookie: BSAUUSER=5240391072; path=/; expires=Mon, 12 Dec 2022 16:16:13 -0500; HttpOnly; secure * But there is still no cookie in the request data.

So the GetCookie() method is returning no cookie value because it is looking in the request.cservervars and it's not there.

FYI, I'm running ISAPI 4.68 WC on IIS 10.

Any other ideas? Doug

Cookies don't show up in cServerVars. Cookies are headers and you need to get them with Request.GetCookie(). To truly check what's happening with cookie creation you should use a tool like Fiddler to see what the server sends and then what the client sends back. The way cookies work, the server sends the initial Set-cookie to set the cooikie on the client, and the client then continues to re-send the cookie until it expires or the browser is shut down.

Certain types of requests (redirects primarily) don't work to set a cookie so you have to be careful on requests that set cookies to make sure the cookie actually makes it to the client.

If you have two applications that are sharing the same cookies you can run into conflicts because the cookies are set at the site root, so if the same cookies are set by two different applications there are going to be conflicts (unless they should be shared). Best to have separate cookies for each site.

+++ Rick ---