Azure deployment error with IW 15.2.63

[zsleo]

I have an application built with IntraWeb Version 15.2.51 that is deployed in Azure on load balanced servers.

All have been working perfectly since April 2022.

I have just rebuilt the app with IntraWeb Version 15.2.63, deployed it and I am now getting an error when I try to access it through the public internet.

502 - Web server received an invalid response while acting as a gateway or proxy server.
There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.


All is fine when I access it through the private VPN



All advice will be appreciated

P.S. I have tried Standalone and ISAPI... with the same results

[Alexandre Machado]

Checking the change log since 15.2.51 I don't see anything that could cause a status 502.

Is this the basic/standard Azure MS load balancer? Does it use the health probe?

Did you try with more than one browser?

Did you activate the exception logger? If so, are you getting any exceptions on the server side?

[zsleo]

1. It does have a health probe
2. Load balancer: Standard
3. Tried Chrome, Edge, Firefox
4. No exceptions being logged
5. *** Embarrassed *** Yes I did activate the Exception Logger BUT I didn't look at the logs Here it one I just ran

------------------------------------------------------------------------------------------------------------------------
Exception message : Your browser is not supported. User Agent string:
Depending on the error condition, it might be possible to restart the application.
Exception class : EUnknownBrowserException
Exception address : 0000000001547A5E
Exception Time : 2022-07-30 15:00:05.222
------------------------------------------------------------------------------------------------------------------------
Application Name : [removed]
Application Version:
Started at : 2022-07-30 14:59:46.712
Running for : 18 seconds
Computer Name : [removed]
Compiler Version : 350
------------------------------------------------------------------------------------------------------------------------
IntraWeb Version : 15.2.63
Multi-session : True
Content Path : C:\inetpub\MedNetSupport\wwwroot\
Session count : 1
------------------------------------------------------------------------------------------------------------------------
Client IP address : 10.110.5.4
Request PathInfo : /
Request Method : GET
Request User Agent :
Cookies Count : 0
------------------------------------------------------------------------------------------------------------------------
[Stack trace is empty]
------------------------------------------------------------------------------------------------------------------------

[Alexandre Machado]

Yes... I believe that this is the cause.

We have explicitly blocked empty user agent strings because there is no reason to allow them. Although UA string is not a required field in a HTTP(S) request, it is advisable (by W3C) to always set it in any request.

What I think you need to look into is if the load balancer is not forwarding the UA string received from a legitimate user (using a real browser), or if this request came from their health probe and then the Azure load balancer thinks that the application is not working.

After some investigation I found a post where a user complains that Azure health probe is not setting the UA string correctly. See here: https://github.com/MicrosoftDocs/azure-d...sues/69155
People on that thread seem to consider this as an Azure bug (and so do I).

The best way to deal with it is creating a session-less content handler to respond to all health probes requests regardless of the UA string. This will avoid that the health probe creates dozens (if not hundreds) of ghost sessions for no reason.

There is no reason for the health probe to send an empty UA either.

[Alexandre Machado]

To give you some background about this (breaking) change that we introduced:

We found out, after monitoring a real user application, that his application was being hit by an enormous amount of health probe requests (not in Azure, though), in the order of hundreds per minute. All of them containing empty UA strings. However in that case, the probe understands the response as valid and knows that the application is live. Azure load balancer seems to be different in that regard.

[Alexandre Machado]

From MS docs:

For example: You configure your application gateway to use back-end servers A, B, and C to receive HTTP network traffic on port 80. The default health monitoring tests the three servers every 30 seconds for a healthy HTTP response with a 30 second timeout for each request. A healthy HTTP response has a status code between 200 and 399. In this case, the HTTP GET request for the health probe will look like http://127.0.0.1/.

https://docs.microsoft.com/en-us/azure/a...e-overview

Once IW responds with 404, the probe will understand this as a server failure... Kind of stupid probe...

[zsleo]

Thanks Alexandre.

Is there some sample code somewhere that creates a session-less content handler?

Best regards

[Alexandre Machado]

The exception above shows that the PathInfo is only '/', meaning that the health check request probably hits the root of your application (using the root url only).

I believe you should create a Custom health probe with a specific URL (e.g http://yoursite.com/healthcheck).

See more about it here: https://docs.microsoft.com/en-us/azure/a...e-overview

This health check could be responded by a content handler created such as in this example:

https://github.com/Atozed/IntraWeb/tree/...ntHandlers

In this example, we create a XML in a session-less content handler.

In your case, you just need something like this:

Code:

function TContentHealthCheck.Execute(aRequest: THttpRequest; aReply: THttpReply; const aPathname: string; aSession: TIWApplication;
aParams: TStrings): boolean;
begin
  Result := True;
  if Assigned(aReply) then begin
    aReply.WriteString('OK');  // You just need to respond anything with a 200 http status code
  end;
end;

You can also create a health check that explores one of the built-in content handlers that IW server has, e.g. this one:

http://yourserver.com/$/blank

IW server responds to this with a blank page, with http status code 200 which is sufficient to validate the health check. This won't require any special code from you.

Please let me know how it goes

[zsleo]

Alexandre,

Sorry I took so long to get back to this. There were other more urgent things to do

I could not get http://yourserver.com/$/blank to work

I did get the Custom Content Handler to work but only after I added a browser check. (See below)

Thanks for your effort. It is very much appreciated.

Code:

procedure TIWServerController.IWServerControllerBaseBrowserCheck(aSession: TIWApplication; var rBrowser: TBrowser);
begin

  if (rBrowser is TChrome) and not rBrowser.IsSupported then
  begin
    rBrowser.Free;
    rBrowser := TChrome.Create;
  end
  else if (rBrowser is TOther)  then
  begin
    rBrowser.Free;
    rBrowser := TChrome.Create;
  end;

  if not rBrowser.IsSupported then
  begin
    rBrowser.Free;
    rBrowser := TChrome.Create;
  end;
end;

[Alexandre Machado]

Great! I'll have a look to understand why the black content handler didn't work. Thanks for your feedback