1. You want your HD videos (16:9 aspect) to look like Cinemascope film (2.35:1 aspect). Image 1 below shows an example of this.
   
2. You've probably encoded your video for DVD/Blu-ray and tweaked those settings for online video and ended up with a video that has an aspect of 4:3 with the picture inside it with the normal aspect but with letterboxing (black bars on the top and bottom). Image 2 below shows an example of this.
   

Image 2: Picture is in HD aspect (16:9) but video is in SD aspect (4:3)

Crop your Cinemascope (2.35:1) Video.

Problems with Letterboxing your Videos

1. The video looks a whole lot better without letterboxing.
2. The picture quality is not as good as what it would be if you cropped your video instead of simply letterboxing.

Why the Picture Quality suffers

Image 3: Cinemascope aspect (2.35:1) picture and video. For Cinemascope video, crop the video to the correct dimensions.

Image 4: HD Video in HD aspect (16:9). Not letterboxing.

I

 

Why does something so simple end up being so difficult

1. The way your camera records and outputs video
2. The editing software you use and the abundant choices it offers for encoding, none of which really seem to apply to what you're trying to do.

HD, HDV, Full Raster

Pixel Aspect Ratio

Video Editing Software

The Solution 

• Choose Square pixels  - Do not choose Widescreen 16:9, HD Anamorphic 1080 or any other option
• Make sure you choose or set the correct dimensions (1920x1080 or 1280x720). For most online video hosting services that support HD video you'd probably choose to encode at 1280x720.

The image below shows and annotated version of Adobe Premiere Pro CS3's Media Encoder screen with the wrong settings.

 

Lets say, you were building a large system and one of it's functionalities was to be able to retrieve information about a certain FedEx package given the Shipment No. What you will do then, is use the "service" provided by FedEx to do this non-interactively (without human intervention) through your system.

Lets imagine that there are other similar "services" you could utilize in your system and you'd like to use these services rather than have to build them yourself. Essentially, you are building a system by "re-using" components that someone else has built and made available to you. It does not matter to you, what platform the service is running under or what tool was used to develop it. All you really care about is that you can find out how to use the service. This means your system is effectively decoupled from these "services" since you're not tied to using these services on a certain platform or using a certain development tool.

Lets sum it up now:

1. Re-useable "components".
2. Platform agnostic.
3. Implementation agnostic.
4. Following certain published specifications/standards.
5. Decoupled or loosely coupled.

SOAP for the Delphi developer

Why SOAP

Most distributed systems today use technologies such as DCOM and CORBA. Systems built with these technologies are:

1. Tightly coupled.
2. Often platform specific and therefore not interoperable.
3. Need to be configured on the client machines.
4. Have security issues, primarily when it comes to firewalls and the ability to get past them without having to punch holes through them to get them to function normally.

So SOAP sets out to achieve:

1. Interoperability.
2. Decoupled distributed systems.
3. Easy access through Firewalls etc.

Essentially, if you want to use a "service" you should not need to know the platform on which this service is running and nor should you be concerned about the implementation details. This is very similar to HTTP and Web Browsers. You can use a Web Browser today and surf the world wide web without the need to know what kind of server is serving you the web pages (platform, server vendor etc.) nor how it is serving you these pages (implementation - static pages, dynamic pages, ISAPI, ASP etc.). All you should need to know, is:

1. What are the methods of the service and parameters to these methods, and the types of these parameters (string, integer etc.)
2. If a method is returning some information, then what are the details of that (parameters, types etc.)

Wire Protocol

For those of you who are interested and know something about HTTP, a typical SOAP packet (including HTTP header) might look like this:

POST http://webservices.matlus.com/MyService HTTP/1.0
Accept: application/octet-stream, text/xml
SOAPAction: "urn:MyServiceIntf-IMyService"
Content-Type: text/xml
User-Agent: Borland SOAP 1.1
Host: webservices.matlus.com
Content-Length: 521
Proxy-Connection: Keep-Alive
Pragma: no-cache

<?xml version="1.0" encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/>
  <SOAP-ENV:Body>
    <NS1:MethodName xmlns:NS1="urn:MyServiceIntf-IMyService" SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>
      <NS1:MethodParameter xsi:type="xsd:string">ParameterValue</NS1: MethodParameter>
    </NS1:MethodName>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Why HTTP as a Transport Protocol

WebService Description Language (WSDL)

1. Where is the WebService located (the URL)
2. What are the methods available
3. What are the parameters and type of these parameters
4. What is being returned (if anything) and what are the types

Ideally, given a WSDL file for a specific WebService, you should be able to build a client application that uses the services of this WebService. If the SOAP and WSDL specs are adhered to, you have all the information you need to start using the service. Similarly, when you build a WebService, you should make sure you adhere to the SOAP and WSDL specs and publish a WSDL file so others can access your WebService without a problem.

WebServices Today and Tomorrow

1. http://www.xmethods.com/
2. http://www.salcentral.com/

Please note, that things will not always be smooth sailing. This is due to a number of reasons, some of them are:

1. Some of these services were built conforming to earlier specs
2. Due to constantly changing specs. Delphi implementation may not always be current. I'm sure Borland on their part will do their best to release patches, fixes, upgrades etc. as soon as possible.

There are about 35-40 implementations of SOAP today. Each employing different methodologies or catering to different platforms and development tools. Most of them are free and most of them do their best to conform to the SOAP spec. At this point in time, differences in conformance are to be expected.

Let the games begin!

Delphi's SOAP Architecture and Implementation

Before I take you into the SOAP world as Delphi sees it, I'd like to touch upon one of the advantages of exiting distributed technologies such as DCOM, CORBA and Java RMI (Remote Method Invocation).

The one thing that these technologies have in common is the concept of a "Stub". In terms of COM and CORBA, this is a type library (IDL). One of the advantages of having a stub, besides the fact that one gets to see the interface of the object (it's methods and their parameters, properties etc.), is that the compiler can help detect errors in code at compile time. In most implementations of SOAP this is one aspect that is missing and developers that have no real need for some of the advantages that SOAP has to offer, see no point in using SOAP simply due to this fact.

Delphi however, has the best of both worlds. Delphi's run time type library has been enhanced and some new classes have been provided to allow for the way SOAP is implemented in Delphi. A brand new interface IInvokable two new classes TRemotable and TRIO and the Invocation Registry, make up the core of how Delphi implements SOAP. You can read about these in the on-line help.

You should also realize, that it is not required, that one accesses an "Object" in a WebService, even though SOAP has the word Object in it. Once a WebService receives a request for a certain method, how it implements this request is totally up to the WebService. It may or may not use an object in its implementation. In Delphi however, we use objects that implement Interfaces. This is not new to the Delphi developer, so when building WebServices with Delphi, you'll find yourself in familiar territory.

Method Invocation - Object Pascal style

Refer to Figure 1

1. A SOAP Request is received by a Delphi built WebService.
2. The SOAP Dispatcher recognizes this to be a SOAP Request and so, hands the Request over to the PascalInvoker.
3. The PascalInvoker, parses the request. After parsing the request, It figures out the class that needs to be instantiated and the method that needs to be called. It instantiates an instance of the required class and calls the appropriate method, sending it any parameters if applicable.

Similarly, when you build a client for the WebService, and your WebService returns an object, an instance of this class/Interface is automatically created for you. That's great is it not? Yes, that's great when you build a WebService and the client that uses this WebService. What about when someone attempts to use your WebService and he or she is using Java on a Mac for example? Here is the beauty of it. The Delphi implementation conforms to the SOAP spec. So when others call on your WebServices, they don't see anything untoward about the response sent back by a Delphi built WebService. It's the way that a Delphi built client interprets the SOAP message (This is handled for you by TRIO or Remote Interface Object) that is unique. In other words, when a Delphi built client application receives a SOAP message as a response to a request, it instantiates instances it requires. That's just the way it has been implemented. Similarly, if you build a Delphi client for a non-Delphi built WebService, you still work with objects if that is how the response gets interpreted. So it doesn't really matter what platform the WebService is running under or the tool used to build it. If you build a WebService client in Delphi you work with classes and interfaces.

The Interface Stub

What about the WSDL

I can image that a lot of the things I've said in this article don't make much sense. It seems to be out of context in a way. I suggest you read the next few tutorials and you'll find things will start to fall in place. Unfortunately, there is so much to be said about so many things, that I can't say much about one thing without including the other. So please bear with me.

1. The Number of Slave Web Modules for Multi-Module ISAPI project
2. Addtional Components (that are part of my package)
3. Output Folder (such as C:\inetpub\scripts)
4. The Host Application (used for debugging)

It should be noted that currently, only the default settings are implemented. That is you can build a multi-module ISAPI extension, you can choose the number of slave modules and you can determine the output folder of the compiled dll and the host application.

The expert then builds one Master WebModule (You can have only one Master WebModule per project), and one or more Slave WebModules (in reality, you don't want any slave modules, until you've named your Master Web Wodule. The reason for this will be explained later). There is also a New Slave Module Expert so you can add additional slave modules at a later time.

{**********************************************}
{  Multi-Module Support for ISAPI Applications }
{       Developed by Shiv R. Kumar (2001)      }
{              Master Web Module               }
{**********************************************}
unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Classes, MsMultiModule, HTTPApp;

type
  TMsMasterWebModule1 = class(TMsMasterWebModule)
    procedure MsMasterWebModuleCreate(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;

var
  MsMasterWebModule1: TMsMasterWebModule1;

implementation

{$R *.DFM}


procedure TMsMasterWebModule1.MsMasterWebModuleCreate(Sender: TObject);
begin
{***************************************************************}
{ If you add Slave WebModules to your project, be sure to       }
{ to include a call to the ModuleFactory of the Salve WebModule }
{ Example usage of ModuleFactory                                }
{ ModuleFactory(TMsSlaveWebModule2, True, True);                }
{***************************************************************}
end;

end.

The Dispatching Mechanism

The Master WebModule's dispatcher fields all requests made on the ISAPI Dll. The Master WebModule's dispatcher handles dispatching requests either to itself, or the other Slave WebModules.

Lets assume the name of the ISAPI dll is Multimodule.dll. A URL like this:

http://www.matlus.com/scripts/multimodule.dll/MyPathInfo

http://www.matlus.com/scripts/multimodule.dll/SlaveModule1/MyPathInfo

Session Management

The Session Management has been built with Remote Session Management in mind and will allow session information to reside across application and machine boundaries. (there is a Port and Server property available at design time as part of the Master WebModule). This feature has not been implemented as yet, but the hooks are in place.

  { TMsSessionManager }
  TMsSessionManager = class(TPersistent)
  private
    FSessionManagerIndentifier: string;
    FSessionManagerTimeOut: DWORD;
    FSessionBroker: TMsSessionBroker;
    FCurrentSessionID: string;
    FServer: string;
    FPort: string;
    FOnBeforeDeleteSession: TOnBeforeDeleteSession;
    procedure SetSessionIdentifier(const Value: string);
    procedure SetSessionManagerTimeOut(const Value: DWORD);
    function GetSessionManagerTimeOut: DWORD;
    procedure SetData(Value: Pointer);
    function GetData: Pointer;
    procedure SessMgrOnBeforeDeleteSession(Sender: TObject; SessionID: string; Data: Pointer);
  public
    constructor Create;
    destructor Destroy; override;
    function CreateSession: string; overload;
    function CreateSession(const TimeOutInMinutes: DWORD): string; overload;
    procedure ClearSessionInfo;
    procedure AddSessionInfo(const Name, Value: string);
    function GetSessionInfo(const Name: string): string;
    procedure DeleteSessionInfo(const Name: string);
    procedure DeleteSession;
    function GetSessionData: TStrings;
    property CurrentSessionID: string read FCurrentSessionID Write FCurrentSessionID;
    property Data: Pointer read GetData Write SetData;
  published
    property SessionTimeOut: DWORD read GetSessionManagerTimeOut write SetSessionManagerTimeOut;
    property SessionIdentifier: string read FSessionManagerIndentifier write SetSessionIdentifier;
    property Server: string read FServer write FServer;{ TODO -oShiv -cFuture : To be Implemented }
    property Port: string read FPort write FPort;{ TODO -oShiv -cFuture : To be Implemented }
    property OnBeforeDeleteSession: TOnBeforeDeleteSession read FOnBeforeDeleteSession write FOnBeforeDeleteSession;
  end;

The Session Management can use Fat URLs, Cookies or Hidden fields. The order of precedence is in that order. By default, the SessionIdentifier is sid, which means when you pass the session id back and forth between the browser and ISAPI, it should be in the form:

  
    http://www.matlus.com/scripts/multimodule.dll/somepathinfo?sid={12805C36-7ABE-4E4D-B6B5-31C3CA0B9BA8}
  

  
    http://www.matlus.com/scripts/multimodule.dll/somepathinfo?sid=
  

If you're using cookies, then it should be in the form

  
    sid={12805C36-7ABE-4E4D-B6B5-31C3CA0B9BA8}
  

If you're using a hidden field then the name of the field should be sid.

The Master WebModule has a property called SessionIdentifier. The value is this property is sid by default. If you change this property to something else, be sure to use this new value everywhere including the special tag .

  
    SessionManager.CreateNewSession;
  

The CreateNewSession method has a default parameter called SessionTimeOut. This property is defaulted to whatever the Master WebModule's SessionTimeOut property is. The Session Manager allows for each session to have it's own timeout. If you need to use this feature, you simply set the value at the time of creating a new session. The timeout value is in minutes.

When you create a new session, the SessionManager.CurrentSessionID is set to a GUID. You should hardly ever need to use this property, since where you need to put the GUID (in html) you can simply use the special tag .

When a Request comes in, the Session Manager automatically puts you in the context of the session. So any operations you do with respect to the Session Manager is with the session that was identified in the URL (or cookie or hidden field).

In practice, you never have to put the GUID in the URL yourself. If the html you send as a Response is in the form

  
    http://www.matlus.com/scripts/multimodule.dll/somepathinfo?sid=<#sid>
  

The Master WebModule will automatically replace the <#sid> tag with the GUID of the current session. So no matter where you put the <#sid> tag in your html, it will be replaced by the Master WebModule's in built PageProducer. This PageProducer understands some other tags as well. Such as:

• <#scriptname> is replaced by: Request.ScriptName
• <#sid name="NameOfSessionItem"> is replaced by the Value of the item
• <#sid name="sessioninfo"> is replaced by an html page listing all the name=value pairs of the current session

Tagging objects with Sessions

procedure TMsMasterWebModule1.MsMasterWebModuleBeforeDeleteSession(
  Sender: TObject; SessionID: String; Data: Pointer);
begin

end;

Since the Data property is a pointer, you are free to tag any object to the session. It could be an ObjectList or a DataModule that has other objects and Objects lists.

Additional Events

In addition to the events of a normal WebModule, the Master WebModule publishes the following events:

    property OnModuleHTMLTag: TOnModuleHTMLTag read FOnModuleHTMLTag Write FOnModuleHTMLTag;
    property OnException: TExceptionEvent read FOnException write FOnException;
    property OnSessionInvalid: TOnSessionInvalid read FOnSessionInvalid write FOnSessionInvalid;
    property OnSessionExpired: TOnSessionExpired read FOnSessionExpired write FOnSessionExpired;
    property OnBeforeDeleteSession: TOnBeforeDeleteSession read FOnBeforeDeleteSession write FOnBeforeDeleteSession;

  TExceptionEvent = procedure (Sender: TObject; E: Exception; var Handled: Boolean) of object;
  TOnSessionInvalid = procedure (Sender: TObject; SessionID: string) of object;
  TOnSessionExpired = procedure (Sender: TObject; SessionID: string) of object;

The Master WebModule has a few "helper" methods as well. They are:

    function ExtractMultipleRequestFields(const FieldName: string): TStrings;
    function GetRequestFieldValue(const FieldName: string): string;

The ExtractMultipleRequestFields coms in handy when you have a multi-select list box in a form and you need to find out which items were selected (The WebBroker framewrork does not support this out of the box). This method (given the field name) returns the StringList containing all the Values that were selected in the list box.

The GetRequestFieldValue makes processing Requests easier since it decouples code from the need to know the type of method (GET or POST) that was used. Frequently, one needs to process boths kinds of Requests in a certain action. Internally, this method determines the method type of the Request and uses either the Request.ContentFields property or the Request.QueryFields property and returns the Value for a given Name.

The (read only) property ModuleName returns the Path and File name of the ISAPI Dll. The read access method of this property uses the GetModuleFileName API.

Handling Special tags - A "Catch All" OnHTMLTag event (built in Page Producer)

Communicating between Slave WebModules and the Master WebModule

{**********************************************}
{  Multi-Module Support for ISAPI Applications }
{       Developed by Shiv R. Kumar (2001)      }
{               Slave Web Module               }
{**********************************************}
unit Unit2;

interface

uses
  Windows, Messages, SysUtils, Classes, MsMultiModule, HTTPApp, Unit1;

type
  TMsSlaveWebModule2 = class(TMsSlaveWebModule)
    function GetMaster: TMsMasterWebModule1;
  private
    { private declarations }
  public
    property Master: TMsMasterWebModule1 read GetMaster;
    { public declarations }
  end;

var
  MsSlaveWebModule2: TMsSlaveWebModule2;

implementation

{$R *.DFM}

function TMsSlaveWebModule2.GetMaster: TMsMasterWebModule1;
begin
  Result := TMsMasterWebModule1(MasterWebModule);
end;

end.

Notice that the expert has included the Master WebModule's unit (Unit1 in this case) in the uses clause of the Interface section. Notice also, that the (read only) property Master, returns a type TMsMasterWebModule1. This happens to be the class name of the Master WebModule at the time of creating the new Slave WebModule.

It is therefore recommended that one should first name and save the Master WebModule (class and unit) before creating additional Slave WebModule. The Expert will then use the unit name and class name when generating the code for the Slave WebModule class.

procedure TMsSlaveWebModule2.MsSlaveWebModule2WebActionItem1Action(
  Sender: TObject; Request: TWebRequest; Response: TWebResponse;
  var Handled: Boolean);
begin
  { Adding "ProductID" to the Current Session as received from a Posted Form }
  Master.SessionManager.AddSessionInfo('ProductID', Master.GetRequestFieldValue('ProductID'));
end;

Registering Slave WebModules

  ModuleFactory(TMsSlaveWebModule2, True, True);

To circumvent this issue in the OnHTMLTag event of your PageProducer, you could have code like this:

procedure TForm1.PageProducer1HTMLTag(Sender: TObject; Tag: TTag;
  const TagString: String; TagParams: TStrings; var ReplaceText: String);
begin
  if AnsiCompareText(TagString, 'sometag') = 0 then
    ReplaceText := 'Something'
  else
  begin
    if TagParams.Text = '' then
      ReplaceText := Format('<#%s>', [TagString])
    else
      ReplaceText := Format('<#%s %s>', [TagString, TagParams.Text]);
  end;
end;

Rule No:1 HTML should not be mixed in with code.

1. Makes the code cleaner and therefore more maintainable/manageable.
2. Speeds up the application quite a bit. (Due primarily to the intricacies related to string handling in 32 bit Delphi)
3. Allows the use of HTML designers (designers being either tools or people) to design the "templates", while you the programmer can code the business rules. (yea right if only we were that lucky!)
4. Allows for changing the page layout of your web sites/applications without the need to re-compile the application.

The TPageProducer has a property called HTMLFile. You should use this property to load up static html templates at run time. If you're having problems loading up files/images at run time due to "path" issues, I suggest reading the article titled - Relative/Virtual Paths Explained.

Defining a Language

I won't go into HTML/JavaScript specific things here, but rather talk about how templates should be designed from the perspective of using a TPageProducer to "process" templates.

Rule No:2 Define a minimal "tag language" that you use over and over again across applications.

1. Streamlining your templates
2. Making your templates more readable/maintainable/configurable
3. When working in a team where there are HTML designers (people) they start to understand your "language" and can start to apply it in templates they build for you.

So what is this language about? It's simple really. It's tags that you "re-use". Tags that have "attributes" that when set control the "behavior" of the processing. Kind of like an object that has properties and setting different properties change the behavior slightly. The more generic you make your tags, the more reusable they become.

1. We use Request.ScriptName wherever we need the "path" of our application to be included in things like hyperlinks, form actions and the like.
2. The action attribute of forms.
3. The target attribute of forms.
4. The src attribute of images.

All your page producers should "understand" this tag (Or at least one PageProducer in your application should). In the OnHTML event you could have code like the following:

If AnsiCompareText(TagString, 'scriptname') = 0 then
  ReplaceText := Request.Scriptname;

Similarly for the "form" tag <#form action="" target="" method="">

if AnsiCompareText(TagString, 'form') = 0 then
  ReplaceText := Format('<form action="%s" target="%s" method="%s" />', [
    TagParams.Values['action'], TagParams.Values['target'], TagParams.Values['method']]);

This kind of tag gives you the flexibility to define attributes in your template while also giving you the flexibility to change them later. Granted, if you're using templates, you could simply change them there (the hard coded value of a form action say). But believe you me a time will come, when you wished you used tags in the template! For example, you might need to change either the target or the action of the form depending on some condition. Instead of having two similar templates (that need to be synchronized each time there is a change) you can have just one.

Rule No: 3 - Get used to coding your html in xhtml style. That is all tags and attributes in lowercase, all attribute values within double quotes and all empty tags closed.

Designing Templates

1. All <input> elements will have one and only one tag.
2. All <select> elements will have one and only one tag.

Of course one could go a step further and say that we need have only one tag for ALL controls. This is the kind of thing I do personally in fact. But I have a component that does this for me (and a lot more). But for this discussion we'll stick to the 2 proposed above.

We won't be talking about the html aspects of the design here (the look and feel). We'll only look at the tags involved. The tags shown below can satisfy our needs for any type of &lg;input> tag we need in our forms:

<#input type="etText" name="foo" value="" maxlength="10" />
<#input type="etPassword" name="foo" value="" maxlength="10" />
<#input type="etHidden" name="foo" value="" maxlength="0" />
<#input type="etCheckBox" name="foo" value="" caption="bar" checked="false" />
<#input type="etRadioButton" name="foo" value="" caption="bar" checked="false" />

It goes without saying that this is only one tag. As a result, we can process these tags using one conditional statement in our code. It's the attributes that make all the difference. The code that processes these tags might look like this:

type
  TMsHTMLElementType = (etText, etPassword, etHidden, etComboBox, etLookUpCombo,
    etMemo, etCheckBox, etRadioButton, etButton, etLabel);
...
...
...
...

implementation

{$R *.dfm}

uses TypInfo;

procedure TForm1.PageProducer1HTMLTag(Sender: TObject; Tag: TTag;
  const TagString: String; TagParams: TStrings; var ReplaceText: String);
const
  sHTMLTextInput = '<input type="%s" name="%s" value="%s" maxlength="%s" />';
  sHTMLCheckRadio = '<input type="%s" name="%s" value="%s" maxlength="%s"%s />nbsp;%s';
var
  sChecked: string;
  sRadioOrCheck: string;
begin
  If AnsiCompareText(TagString, 'input') = 0 then
    case TMsHTMLElementType(GetEnumValue(TypeInfo(TMsHTMLElementType), TagParams.Values['type'])) of
      etText    : ReplaceText := Format(sHTMLTextInput, ['text', TagParams.Values['name'],
                    TagParams.Values['value'], TagParams.Values['maxlength']]);
      etPassword: ReplaceText := Format(sHTMLTextInput, ['password', TagParams.Values['name'],
                    TagParams.Values['value'], TagParams.Values['maxlength']]);
      etHidden  : ReplaceText := Format(sHTMLTextInput, ['hidden', TagParams.Values['name'],
                    TagParams.Values['value'], TagParams.Values['maxlength']]);
      etCheckbox,
      etRadioButton:
        begin
          if AnsiCompareText(TagParams.Values['type'], 'etCheckBox') = 0 then
            sRadioOrCheck := 'checkbox'
          else
            sRadioOrCheck := 'radio';
          if AnsiCompareText(TagParams.Values['checked'], 'true') = 0 then
            ReplaceText := Format(sHTMLCheckRadio, [sRadioOrCheck, TagParams.Values['name'],
              TagParams.Values['value'], TagParams.Values['maxlength'], ' checked="checked"', TagParams.Values['caption']])
          else
            ReplaceText := Format(sHTMLCheckRadio, [sRadioOrCheck, TagParams.Values['name'],
              TagParams.Values['value'], TagParams.Values['maxlength'], '', TagParams.Values['caption']])
        end;
    end;

end;

Similarly, you could define a tag that (depending) on an attribute can become either a Combo Box or a List Box. Better yet, if it's a list box, whether it's a multi-select list box or a normal list box. You can then go on to define a "data aware" combo box tag that will allow you to define the stored procedure to use to populate it, the "name" field, then "value" field and so on.

Sooner or later you're going to want to build a specialized descendant component that does all of this for you thus allowing you to reuse your vocabulary. That's what object oriented programming is about. So don't let anyone stop you!

One could go in all sorts of directions with this concept. For instance, you could define a template that has a special tag like so:

<#embedtemplate filename="">

buried deep inside it somewhere. The filename attribute is the name of another template, a template for an html form for instance. That way, the same basic template can be used over and over throughout your system. You could even determine the embedded template to use at run time. Or the template to use is determined by the value of a parameter in the URL or content fields of a posted form. It's up to you really. But where ever you do, make sure the concept is re-usable and is generic enough to be reusable. Give a lot of thought to naming your tags and the attributes they can/should have.

<html>
  <head>
    <link rel="stylesheet" type="text/css" href="<#statevar name="StyleSheet">
    <title><#title></title>
    <script>
    <#script>
    </script>
  </head>
<#body>
  <table border="0" cellpadding="0" cellspacing="0" width="100%" align="" valign="">
    <tr>
      <td colspan="2">Page Header goes here</td>
    </tr>
    <tr>
      <td><#embedtemplate id="1" name="LoginForm"></td><td><#childtemplate></td>
    </tr>
    <tr>
      <td colspan="2">Page Footer goes here</td>
    </tr>
  </table>
</body>
</html>

A Template that Shows Database information

Take a look at the template below:

<table>
  <tr class="tableheaderrow">
    <td class="tableheadercell" align="center" style="font-size: smaller;">Customer ID</td>
    <td class="tableheadercell" align="center" style="font-size: smaller;">Company Name</td>
    <td class="tableheadercell" align="center" style="font-size: smaller;">Address</td>
  </tr>
  <tr class="tablerowrow">
    <td class="tablerowcell" align="center" style="font-size: smaller;"><#fieldvalue fieldname="CUST_ID "></td>
    <td class="tablerowcell" align="center" style="font-size: smaller;"><#fieldvalue fieldname="COMPANY_NAME"></td>
    <td class="tablerowcell" align="center" style="font-size: smaller;"><#fieldvalue fieldname="ADDRESS "></td>
  </tr>
</table>

Given a dataset that holds a record, the code to process this template might look like this:

  if AnsiCompareText(TagString, 'fieldvalue') = 0 then
    ReplaceText := MyDataSet.FieldByName(TagParams.Values['fieldname']).AsString;

The next thing that comes to mind is; "Ok, now how do we do this for a record set that contains a number of records?". This is probably a more common need than the previous one. So let's explore this case a bit. The solution is to break up your templates in "snippets".

1. A Main "Table" template
2. A Header Template
3. A Row Template
4. A Footer Template

The Main "Table" template essentially, has "place holders" for the other templates. This template might look like this:

<table border="0" cellpadding="0" cellspacing="0" width="100%" align="" valign="">
  <tr>
    <#tableheadertemplate name="SoAndSoTableHeaderTemplate">
  </tr>
  <#tablerowtemplate name="SoAndSoTableRowTemplate">
</table>

Notice that the "insertion" point where "Rows" are inserted does not have the <tr> tags around it. Unlike the tag for the header.

Using the earlier templates as a starting point, the header template would look like this:

    <td class="tableheadercell" align="center" style="font-size: smaller;">Customer ID</td>
    <td class="tableheadercell" align="center" style="font-size: smaller;">Company Name</td>
    <td class="tableheadercell" align="center" style="font-size: smaller;">Address</td>

The Row Template would look like this:

  <tr class="tablerowrow">
    <td class="tablerowcell" align="center" style="font-size: smaller;"><#fieldvalue fieldname="CUST_ID "></td>
    <td class="tablerowcell" align="center" style="font-size: smaller;"><#fieldvalue fieldname="COMPANY_NAME"></td>
    <td class="tablerowcell" align="center" style="font-size: smaller;"><#fieldvalue fieldname="ADDRESS "></td>
  </tr>

Notice that the "row" template has the <tr> tags, while the "header" template does not.

I hope this article has shown you how best to utilize the power of the TPageProducer component.

Web sites on the Internet are known by their Domain Names, such as www.Microsoft.com / www.Datasourceinc.com. Domain names actually resolve to an IP address such as 207.176.25.218. So actually, to get to the DataSource web site one could actually type in http://205.177.16.151 and the browser will take you to the site. But remembering numbers such as these is not easy and so Domain Names were introduced. Domain Names (that end in - .com or .org) have to be registered with an organization called INTERNIC. There is an annual charge of $35 for this registration and the Domain Name has to be unique! When one types in a domain name, the browser actually goes to Internic's DNS (Domain Name Service) server, that resolves the Domain name to an IP address from a lookup database and gives the browser the IP address of the web site in question. The browser then goes to the IP Address. The IP address is also a unique Address. No two servers on the same network can have the same IP address. The WWW can bee looked at as one big network. Each server on the Internet can be uniquely identified by its IP address. So it follows that typing in the IP address will be a lot faster than using the domain name.

Transfer Control Protocol / Internet Protocol. This is the protocol used by the WWW. For this protocol to work we have what are called clients and servers. These are software applications that can "talk" to each other. The server application has to be up and running and "listening" on a certain port number (just a number from 1 to 65535). The client application that wants to talk to the server application must use the same port number and must know the IP address of the server application. Once a connection is established between the client and server, the two can communicate.

Services such as HTTP, FTP, POP, SMTP are what are called "known services" and therefore use a fixed port.

HTTP: Port 80

FTP: Port 21

POP: Port 110

SMTP: Port 25

Again, the names of the service can be used instead of the port No., such as http://www.datasourceinc.com actually resolves to http://205.177.16.151:80. This really tells the browser and the server to use the HTTP protocol on port 80. Since port 80 is the default port, one need not specify it (and so one normally does not). One is free to use any port for "unknown services". On any one server machine/PC one can have one and only one server application listening on a port. So for a given IP address (that uniquely identifies a PC), you can only one server application listening on a given port.

Web servers are both a physical machine as well as a software application that is listening on port 80. An FTP server is another application (also called service or more accurately TCP/IP service) listening on port 21. So you could have both, an HTTP server (Web server) and an FTP server on one single machine, since they use different ports.

Also one can build ones own TCP/IP applications that "talk" across the Internet using a certain port. The server application needs to be listening on a certain port and the client application needs to know the IP address and the port to use. Only clients can connect to servers. Servers can not initiate a connection by themselves. Servers typically "service" multiple clients and so the name - Server. To learn more about TCP/IP and protocols take a look at th eTCP/IP tutorials in the Tutorials section on my web site.

One can have multiple web site on a single machine. The web server (application) has a way of understanding which site is required by which HTTP request it receives. Web servers have what is known as the "root" folder. The root folder is the equivalent of the "C:\" folder of the hard drive. This root folder can be any subfolder on the HDD but the server needs to be informed of it's root folder. The web server in turn can not "see" anything before this root folder. This is to provide for some form of security. The root folder is the starting point for the web server. It can "see" all the folders and subfolders in its tree. Most folders are read access only but some are read/write/execute access. Normally, one of the subfolders of the web server is /scripts (or /cgi-bin) and it is only this folder that has read/write/execute access.

The home page is an HTML page in the root folder by the name default.htm. So when a surfer types in the URL (Uniform Resource Locator) for your web site, the web server (application) looks for a file in its root folder by the name default.htm and sends it back, to the surfer's browser via TCP/IP or more accurately the HTTP protocol which is nothing but a layer over the TCP/IP protocol. The most common and the easiest way to have a web site is to have numerous HTML pages as physical files on the server that are hyper-linked to help navigate through the web site. This kind of site is also called a static web site. Each time you want to make a change to the web site, you have to edit/change/add the HTML pages you want. For large sites this can be a nightmare to manage. Most sites are a mix between dynamic pages and static pages. If some of your web site's information needs to come from a database of some kind, these pages need to be generated dynamically (on request) by some form of script (application programs). Examples are CGI, ISAPI, ASP etc. For your information, the contents of this page are stored in a database. When you linked to this page, an ISAPI application extracted the information for this particular page from a database and dynamically converted the information into HTML format and sent it back to you, for you to see in your browser. In fact this web site is 100% dynamic, which means there are no static HTML pages on the server's hard disk. All content resides in a database and is servered to you dynamically.

Since HTML is very "static" and does not "respond" to the surfer of your web page, Dynamic HTML was introduced. DHTML is a combination of HTML and JavaScript or VBScript. Combining HTML with a scripting language allows for a more dynamic or active web page. Due to scripts embedded within the HTML document the browser is able to respond to certain events, similar to normal event driven programming tools. Events such as mouse moves, mouse clicks etc. are exposed by the browser to your HTML page and the HTML page can in turn "react" to these events. In this way, the HTML pages produced seem to be more responsive or alive than regular static (HTML) pages.

One needs to know one of the scripting languages in order to create DHTML pages. Further, DHTML is supported only by version 4.0 of both IE and Netscape. JavaScript is supported by IE and Netscape while VBScript is supported only by IE. The level of support differs between these browsers. This means that certain DHTML pages may not "work" on all browsers unlike pure HTML (HTML version 3.0 is supported by most browsers in the market today).

ActiveX is Microsoft's answer to Java applets. Once again ActiveX is supported only by IE version 3.02 onwards, and not by Netscape. Java applets are supported by both IE (3.02 and above) and Netscape versions 3 and is also Windows platform dependent. Besides the incompatibility issue there is a big security risk with ActiveX on a web page. The ActiveX control or document is fully capable. In that, it can access any resource on the PC. It has full access to the Win32API and all of the drives and folders. Ironically, it's these "benefits" that are the downfall of ActiveX. ActiveX is better implemented in an Intranet environment where the platform is the same, the browser versions are compatible and the ActiveX document comes from a trusted source (such as the internal IT department).

Java applets on the other hand are platform independent. But once again, it due to it's benefits that it has limitations. The fact that these applets are platform independent means that these applets can not make use of certain functions (API or the UI capabilities) of the operating system. The moment an applet tries to use platform specific features it looses its platform independence. For a Java applet to run in the browser the target machine needs to have the JVM (Java Virtual Machine) installed on it to be able to interpret the Java byte code in the applet. The JVM comes in many flavors and versions and is most times the cause for applet misbehavior on certain machines. Once again, Java Applets are best suited in an Intranet environment where the environment can be better controlled. Java Applets that are very basic in functionality and made for earlier versions of the JVM are and can be used in Internet applications provided of course that the browsers' version understands them.

Seeing that static HTML is very limited in what it can do, web server developers designed a way to allow programmers to extend their capabilities by providing server extensions. Server extensions in their simplest form a scripts that are executed on the server side with the help of interpreters. Examples of these are Perl and Rexx and later came JavaScript and VB script. Scripts allow for server side processing and return HTML pages. Scripts allowed for data access on the server side as well. So with the help of a script, one could query a database local to the server and in return, send back the result set in the form of HTML that the web server sends back to the requester. CGI (Common Gateway Interface) is the interface that most web servers understand. This interface allows web pages to send parameters to the script via the URL and the script processes these parameters and sends back the information via the standard I/O.

Win-CGI is specific to the Windows platform and Microsoft's Internet Information Server (IIS) and other compatible web server software. Here, the parameters are sent to the CGI application (normally a .exe file) via an .ini file. The script in turn writes data (the result) in this same .ini file which the web server reads and send back to the requester.

ISAPI (Internet Server Application Programming Interface) is specific to IIS and other IIS compatible web server software. Microsoft, went a step further (after Netscape introduced NSAPI - Netscape Server API) to provide more functionality and faster response by introducing the Internet Server API. Using this API, one has access to the web server's functionality. ISAPI application can be written with any tool that produces a compiled native machine code output. The compiled code is generated in the form of a DLL (Dynamic Link Library). This DLL is loaded into memory by the web server upon the first request (by a web page) and is kept in memory until the HTTP service is stopped or the machine is re-booted. ISAPI applications have no limitations on the number of parameters that can be passed to them (CGI applications have a limit of 255 bytes). Further, the way the data is transferred or handed to the ISAPI is much faster than the way CGI applications are pass information to and fro.

CGI applications are generally .exe files. This means that each time a request is made via the web server, an instance of the exe is loaded into memory and the data passed to it. This exe file is later unloaded once its job is done. So, if you had 100 surfers hitting your site simultaneously and making the same request, you'll actually have 100 instances of the CGI application, all loaded in memory at the same time. The system resources required for such a feat are phenomenal. Besides that, the time it takes for an instance of a CGI application to load and initialize causes a performance hit.

ISAPI applications on the other hand are DLL files. A DLL is run in the process of the calling application (in this case the web server application) and only one instance is loaded. The ISAPI DLL has to be built in such a way as to incorporate safe multi-threading. For each request, the web server spawns a new thread and does not need to load and initialize the ISAPI application. Since there is no load time involved and multi-threading is employed instead of multi-instancing, the system resources required are at a minimum and the response times are far less than those with CGI applications.

On the other hand CGI applications, by virtue of the fact that they are .exe files and don't need to cater for multi-threading are far simpler to build than ISAPI applications. Also, since an ISAPI runs in the process space of its calling application has the capability of crashing the calling application if errors are not handled internal to the DLL. Basically, this means that if an ISAPI DLL crashes, it takes the web server application down with it. This means all web-sites hosted by that web server will not be accessible until the machine is re-booted. This is one of the primary reasons ISPs (Internet Service providers such as AOL, Erols etc.) do not allow ISAPI applications.

Web applications or browser based applications use the browser as the front end with some form of web server extension application (CGI/ISAPI/NSAPI/ASP) running at the back end. Ideally these applications are a very powerful technology. They are zero configuration thin clients. Which means, the surfer has to do nothing on his/her PC to be able to use these applications. They are platform independent as well as browser and browser version independent. But in reality, these applications are never zero-configuration. Due to the speed with which technology is moving and the inability of individuals to keep upgrading their machines, operating systems and browsers, the zero configuration thin client can not use the new and emerging technologies. Thus browser- based applications will always have to built to conform to earlier versions of operating systems as well as browsers.

Besides the compatibility issues stated above, browsers, by their very nature are isolated from the PC, such that they can not access the resources of the machine they are running on. Therefore they are very limited in their capability to integrate/interface with existing systems or use the Os's API or GUI capability for better and more functional/feature rich UIs. Even in corporate environments, where operating system versions and browser versions can be controlled, these kinds of applications are not the best suited for such a need as 9 times out of 10, these applications will need to interface/integrate with existing systems in the corporate environment.

Browser based application therefore tend to be used for very simple needs.

These are applications built as normal PC based applications but access data over the Internet. Effectively, these applications use the Internet infrastructure as their network. This allows for remote connectivity to data from anywhere in the world. Similar to browser based applications. With the advantage of being able to access the resources of the machine on which they are executed and thereby allowing for integration with other existing corporate systems.

On the GUI side, these applications are fully capable, thus allowing for "standard" features such as drag/drop, tree-views and list-views (like in windows Explorer [not Internet Explorer]). This not only gives the user of the application an interface s/he is familiar with but also saves on training needs. The UI is not limited in any way.

Advantages and Disadvantages of Web based and Internet based Applications

Each technology has its place. Where a simple data entry, data view and reporting capability is required, browser based applications are very well suited. On the other hand, if you require the full functionality and capability of a standard PC application as the front end, but need the "remote" connectivity as well, then Internet enabled applications are ideal. In most corporate scenarios, you will find a combination of browser based and Internet enabled applications. For the simple user or "on off" user (surfer) you'll find a web interface and for the power/corporate user you'll find Internet enabled applications.

When the user/surfer is unknown, that is the browser type, platform etc. in not known or controllable, a browser-based application has its advantages. On the other hand, if cross-platform is not an issue and the environment can be controlled to a high degree, then Internet enabled applications are the right choice, due to their interfacing/integrating capability and UI capability.

Figure 1: Showing the Process of a client request in terms of a browser and web server

As shown in Figure 1:

1. The client sends a request to the web server via an HTTP GET or POST method.
2. The connection persists while the web server spawns a new process to handle the request.
3. The CGI application processes the request, builds the output and sends it back to the web server.
4. The Web server adds the protocol (HTTP) headers and passes all of it back to the requesting client.

ISAPI

Looking at Figure 1 again, let see what would happen if the CGI executable were to be replaced by an ISAPI extension application.

An ISAPI application, does not spawn a new process after it has been called the first time by a request. Rather, it runs in the server's process space, thus reducing both memory overhead and startup time. Only a single copy of this server extension is loaded and is then shared if additional client requests for the same application come in. Furthermore, once an ISAPI application is loaded into the process space, it stays loaded until IIS is stopped and restarted, or until some unspecified period when IIS decides to unload it. This means new requests for the ISAPI will get much quicker responses and resource utilization is kept low due to a single instance model, rather than a multiple instance model in the case of a CGI.

All in all, this speed improvement is a strong argument for using ISAPI to do anything that requires back-end server processing over a CGI. If one were to look at CGI scripts or any other scripting mechanism, its easy to see that these types of applications will perform far slower than even CGI executables as they are interpreted rather than compiled. One should also note, that the interpreter needs to be loaded in memory to do its job as well. So resource utilization is much higher in scripting mechanisms such as, Perl, ASP etc. and performance is poor due to the interpreted nature.

As per Microsoft

Designing High-Performance ISAPI Applications

ISAPI is the highest-performance interface for Web applications. If you create an ISAPI extension or filter, it will outperform ASP scripts or even components performing similar tasks.

However, the inherent speed of the ISAPI interface does not mean that you can ignore performance and scalability considerations. Indeed, ISAPI cannot utilize much of the application support services provided by ASP and COM. If you would like your ISAPI application to maintain session state, for instance, much of that session-state functionality would have to be implemented by you.

Quote continues...

Here are some suggestions for improving the scalability and performance of your ISAPI extensions:

• Avoid ISAPI filters, unless adding an ISAPI filter is absolutely necessary to your application architecture. You should especially avoid filters that perform processing on raw incoming or outgoing data. If you determine that a filter is absolutely necessary, be sure to carefully optimize the main code paths through the filter event notification code.
• Create your own worker thread pool, so that the main I/O threads can be freed to accomplish other tasks. This option is available only for ISAPI extensions, and not for ISAPI filters. For more information about how IIS processes requests, see IIS Request Processing. A sample that demonstrates a worker thread pool, implemented in an ISAPI extension, is available in ISAPI Examples.
• Consider using asynchronous operations and I/O completion ports, when feasible. IIS supports asynchronous reading and writing by using the I/O completion ports, available in Windows NT 4.0, and Windows 2000 or later. Depending on the type of I/O operations being performed, asynchronous operations can make better use of the CPU time available, and generally work particularly well when implemented using a worker thread pool.
• ISAPI extensions should use the Win32 TransmitFile function, exposed by the HSE_REQ_TRANSMIT_FILE ServerSupportFunction.
• Use Connection: Keep-Alive headers. Keeping persistent HTTP connections will provide better performance than using non-persistent connections, in most cases.
• Minimize need for thread synchronization by maintaining state information with the request context. If thread synchronization is required, make sure that critical sections are kept short.
• If your ISAPI application uses the heap intensively, consider other heap alternatives. Intensive use of the Windows? heap can cause resource contention. Several memory allocation alternatives are worth exploring, including:
  • Heap Partitioning, accomplished by creating multiple custom heaps, in addition to the default process heap. Each custom heap would then be controlled by a separate, non-global lock, and lock contention would be reduced.
  • Cached Allocation, which involves using custom allocation operations that operate at a middle layer between the object users and the heap. Calls to the Win32 heap are made infrequently, and only for large memory blocks. These blocks are then subdivided and managed by the custom allocator.
  • Stack Allocation, using the C run-time function _alloca to allocate memory for your objects on the stack instead of the heap. This method is feasible only for relatively small objects, because the space available on the stack is limited. In addition, your newly allocated object will be available only within the current functions, or functions called by that function. Once the current function returns, the storage allocated on the stack will be lost.
• Object Encapsulation, accomplished by simply incorporating a buffer as a member data structure of a class. This buffer is then used for tasks that would otherwise require accesses to the Win32 heap.
• Avoid using global locks within your ISAPI, if possible. Global locks can often adversely affect scalability.

An intersting page on the Microsoft site compares ASP and ISAPI performance, scalability etc. Check it out here

ISAPI and the Web Application Architecture

• Highest performance: A properly planned, developed, and used ISAPI-particularly ISAPI extensions-can outperform any other Web application technology available currently for IIS.
• Low-level control: From an ISAPI extension or filter, you have access to the whole array of Win32 API functions. For instance, you can create a customized worker-thread pool for your ISAPI extension to speed processing, using the Win32 thread functions to access the native thread functionality of Windows 2000.
• Often, ISAPI extensions and filters are best positioned to solve critical bottlenecks in your Web application-especially if you expect scalability to be an important issue for your application, due to high traffic volumes. For instance, if you would like to create your own Web search application on IIS, creating the actual search engine with ISAPI might be the best option if fast performance and scalability are an important goal.

What are Cookies?

Overview

This simple mechanism provides a powerful new tool, which enables a host of new types of applications to be written for browser-based environments. Shopping cart applications can now store information about the currently selected items. The server side of the connection controls the storage of information on the client. The information can be stored for a length of time or only during that current session. The current session terminates when the browser (application) on the client side of the connection is closed. The server side of the connection has access only to information that it stored. This forms a kind of protection mechanism in that, a server can not get information that another server had previously stored.

Specification

This is the format a web application would use to add cookie information to the HTTP headers.
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure

NAME=VALUE

expires=DATE

Note: There is a bug in Netscape Navigator version 1.1 and earlier. Only cookies whose path attribute is set explicitly to "/" will be properly saved between sessions if they have an expires attribute.

domain=DOMAIN_NAME

Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: ".com", ".edu", and "va.us". Any domain that fails within one of the seven special top-level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT". The default value of domain is the host name of the server, which generated the cookie response.

Use 127.0.0.1 instead of localhost in your URLs when building and testing applications locally.

Using localhost will not persist cookies on the target (local) machine.
This issue has been one of the key factors related to issues programmers have when using cookies in the web applications/web sites.

path=PATH

secure

Syntax of the Cookie HTTP Request Header
When requesting a URL from an HTTP server, the browser will match the URL against all cookies and if any of them match, a line containing the name/value pairs of all matching cookies will be included in the HTTP request (automatically). Here is the format of that line:
Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 ...

Additional Notes

procedure SetCookieField(Values: TStrings; const ADomain, APath: string;
   AExpires: TDateTime; ASecure: Boolean);

Every access to a resource (for example, a file, an HTML page, an Internet Server API (ISAPI) application, etc.) is done by the services on behalf of a Windows NT user. The service impersonates the user by supplying a username/password pair in the attempt to read/execute the resource for the client. IIS starts the process using the CreateProcessAsUser System API.

The Windows NT File System (NTFS) allows Access Control Lists (ACLs) to be assigned to files and directories. ACLs grant and/or deny access to the associated file or directory by specific Windows NT user accounts, or groups of users. When an Internet service attempts to read or execute a file on behalf of a client request, the user account offered by the service must have permission, as determined by the ACL associated with the file, to read or execute the file, as appropriate. If the user account does not have permission to access the file, the request fails, and a response is returned, informing the client that access has been denied. File and directory ACLs are configured using the Windows NT File Manager.

Anonymous Connections

1. An FTP client logs on with the username Anonymous.
2. All Gopher requests.
3. A WWW (HTTP) request's headers do not contain a username and password.

The anonymous-logon user account can be viewed and modified on the Service property page of the Internet Service Manager. Multiple Internet Information Server services running on the same computer can use the same, or different anonymous-logon user accounts. Including the 'anonymous logon' user account in file or directory ACLs allows for precise control of the resources available to 'anonymous' clients.

The anonymous-logon user account specified must be a valid Windows NT user account on the server computer, and the password specified must match the password for this user in the computer's user database. User accounts and passwords are configured using the Windows NT User Manager.

When the Internet Information Server product is installed, Setup creates a user account on the server computer to be used for anonymous connections. The username of this account has the form IUSR_<computer_name>. For example, if the server computer name is MATLUS, the username created will be IUSR_MATLUS. The same anonymous-logon user account is set up for all Internet Information Server services installed on the computer. The account is made a member of the computer's Guest group. This will, in most cases, give anonymous client requests access to public content published on the server. Run the Control Panel/Network applet to see the computer name configured for the Windows NT Server computer.

A randomly generated password is created for the IUSR_ account. For maximum convenience and security, we suggest that you change the password associated with this account to a password that you will remember, but is not easily guessed. To do this, you must specify the new password for the account in User Manager, and on the Service page of the Internet Service Manager for each Internet Information Server service installed.

When the Internet Information Server is installed on a primary or secondary domain controller, the anonymous-logon user account is created in the user account database of the domain. When Internet Information Server is installed on a domain member-server, or a stand-alone server, the account is created on the local machine.

If Internet Information Server is installed on multiple domain controllers of the same domain, a separate user account is created in the domain user database for each Internet server computer. This does not cause any conflicts since each username is unique, containing the name of the associated computer.

However, you may find it more convenient to create a single anonymous-logon user account in the domain to use for all Internet Information Server domain controllers in the domain. This can simplify administration of ACLs.

Client Requests Containing Credentials

1. An FTP client logs on with a valid Windows NT username and password. This requires that the FTP service checkbox labeled Allow Only Anonymous Connections be unchecked. WARNING: FTP sends passwords across the network in clear text.
2. A WWW (HTTP) request's headers contain a username and password. This is HTTP Basic Authentication.WARNING: HTTP Basic Authentication sends passwords across the network in clear text.
3. A WWW browser supports NTLM (Windows NT native) authentication, and an anonymous client request is denied access to a resource. In this case, the browser automatically sends the Windows client's username and password to the Internet Information Server Web server using the encrypted NTLM protocol. Currently only IE browser 2.0 and above support NTLM authentication.

For WWW (HTTP) only, when an anonymous request fails because the anonymous-logon user account does not have permission to access the desired resource, the response to the client indicates which authentication schemes the service supports. This is determined by the configuration of the WWW service authentication features. If the response indicates to the client that the service is configured to support HTTP basic authentication, most Web browsers will pop up a username/password dialog box, and reissue the anonymous request as a request with credentials, including the username and password entered by the user.

If a Web browser supports NTLM authentication, and the Web service is configured to support NTLM authentication, an anonymous WWW request failing due to permissions, will result in automatic use of the NTLM protocol to send a username and encrypted password from the client to the service. The client request will then be reprocessed, using the client's user information. The user account obtained from the client is that with which the user is logged into the client computer. As this account, including its Windows NT domain, must be a valid account on the Web server machine, NTLM authentication is most useful in an intranet environment, where the client and server machines are in the same, or trusted domains. Internet Explorer for Windows 95/98 is the only browser that supports NTLM authentication.

Internet Service Manager Authentication Options

For WWW:

1. Allow Anonymous. When this check box is checked, anonymous connections are processed, and the anonymous-logon username/password are used for these connections. When this checkbox is unchecked, all anonymous connections are rejected. In this case, basic or NTLM authentication can be used to access content.
2. Basic Authentication When this check box is checked, the Web service will process requests using basic authentication. WARNING: Basic authentication sends Windows NT usernames and passwords across the network without encryption. This checkbox is unchecked by default for security reasons.
3. Windows NT Challenge/Response. When this check box is checked, the service will honor requests by clients to send user account information using the Windows NT Challenge/Response (NTLM) protocol. This protocol uses encryption for secure transmission of passwords. The NTLM authentication process is initiated automatically as a result of an 'access denied' error on an anonymous client request. Currently, NTLM authentication only works with Internet Explorer 2.0 and above.

How NT Challenge/Response works

Next, your Web server duplicates this computation using the user's account password information, and compares this result to the user's result. If both results match, your Web server recognizes that the user has the correct password and grants access.

Your server will not switch to another authentication method if the user is initially denied access. Instead, the user's Web browser will prompt the user for a user name and password, which the browser will process and send to your Web server as part of the Windows NT Challenge/Response authentication protocol. If this second authentication attempt fails, the user will be denied access to the Web server.

You will find Windows NT Challenge/Response authentication useful in an Intranet environment only, where both user and Web server computers are in the same, secure domain. Additionally, you can only use Windows NT Challenge/Response to authenticate users that logon with Web browsers capable of supporting this method. Currently, Microsoft Internet Explorer version 2.0 or later is the only Web browser that supports Windows NT Challenge\Response.

For FTP:

Allow Anonymous Connections. When this check box is checked, FTP logons in which the user enters a username of 'anonymous' will be processed. These anonymous connections will be processed on behalf of the Windows NT user account specified on the Service property page. When this check box is unchecked, users will be required to enter valid Windows NT usernames and passwords to log on to the FTP service.
1. Allow only anonymous connections. When this checkbox is checked, user logons with a username other than anonymous will be rejected. WARNING: FTP User names and passwords are sent across the network in clear text. When this check box is unchecked, Windows NT passwords will be sent to the server without encryption. This check box is checked by default for security reasons.

Other Authentication Issues

SSL is a WWW feature that supports data encryption and server authentication. All data sent to or from the client using SSL is encrypted. If HTTP basic authentication is used in conjunction with SSL, the username and password are transmitted after being encrypted by the client's SSL support

'INTERACTIVE' and 'NETWORK' Users

If you use the predefined Windows NT user accounts 'INTERACTIVE' and 'NETWORK' for access control, your use of these accounts may affect client access to some resources. In order for a file to be accessed by anonymous client requests or client requests using basic authentication, the requested file must be accessible by the INTERACTIVE user. In order for a file to be accessible by a client request using NTLM authentication, the file must be accessible by the NETWORK user.

Log On Locally User Right

In User Manager, when configuring a Windows NT user account to be used either as the Internet Information Server anonymous-logon account, or as a user account specified by client requests using HTTP basic authentication, be sure that the user account is granted the 'Log on locally' user right. This is specified in User Manager's Policies menu.

Customized Authentication

Digest Authentication

In order to use Digest Authentication in Windows 2000, the server must have access to an Active Directory Server that is set up for Digest Authentication.

If the server running IIS is not a Active Directory Server, or does not have access to the Active Directory, this authentication will not work. For more information about making the server a Directory Server, see the Windows 2000 documentation.

If the server is already a Directory Server, perform the following steps:

1. Open the Active Directory Users and Computers.
2. Open the domain that you want to administer.
3. Double-click the user name that you want to use with Digest Authentication.
4. In Account Options, select Store password using reversible encryption.
5. Click OK.
6. Reset the user's password now in order for the encryption to take place. To reset the user's password, right-click the user name in the directory and click Reset Password.
7. Click OK.

1. Open Internet Services Manager.
2. Expand the Web server that you want to make the change in, and then open the Web site's properties.
3. Click the Directory Security tab.
4. Under Anonymous Access and Authentication Control, click Edit.
5. Select Digest Authentication from the list, and then click OK,

Basic Authentication Scheme

Upon receipt of an unauthorized request for a URI within the protection space, the server should respond with a challenge like the following:

  WWW-Authenticate: Basic realm="DelphiTutorials"

To receive authorization, the client sends the user-ID and password, separated by a single colon (":") character, within a base64 [5] encoded string in the credentials.

  basic-credentials = "Basic" SP basic-cookie
  
  basic-cookie      = 
  
  userid-password   = [ token ] ":" *TEXT

  Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Security Ramifications for IIS Applications

Anonymous Authentication

You can change the account that is used for anonymous authentication in Internet Service Manager. You can also change the security privileges for the IUSR_<servername> account in Windows NT User Manager. Be aware that any changes will result in changes to every anonymous HTTP request that is serviced by IIS. Also note that if the anonymous account configured in Internet Manager does not have the "Log On Locally" right (not a right given to "Guest" accounts by default on domain controllers), then IIS will not be able to service any anonymous requests. The IIS installation specifically gives you the "Log On Locally" right to the IUSR_<servername> account.

Most resources, such as the IUSR_<servername> account, that allow Guests to access them, do so by allowing access to the special group "Everyone." You can set permissions on files and other resources specifically to allow or disallow the IUSR_<servername> account to access them, but most people end up managing access by controlling access to the groups "Everyone" or "Guests."

Basic Authentication

Because Basic authentication provides the username and password credentials to IIS, access to items that require credential knowledge can successfully be performed when using Basic authentication. For example, if an ISAPI application mapped a drive letter across a network, then it would require knowledge of the current user's credentials. Because IIS is given the username and password credentials as part of Basic authentication, this task will succeed if the account specified has access to the network resource.

Windows NT Challenge/Response Authentication

Because of the one way encryption is used, NTLM authentication validates the user for IIS without providing knowledge of the user's password to IIS. Therefore, a full set of username and password credentials is not available to IIS for doing such tasks as mapping a network drive. If an ISAPI application calls WNetAddConnection2 without specifying a username and password, it will fail under NTLM authentication.

Multiple Authentication Schemes Selected

It is worth noting that if both NTLM and Basic authentication schemes are checked, IIS responds to requests indicating that both schemes are acceptable. It is up to the client to determine which authentication schemes it supports and to respond appropriately. For browsers, such as Internet Explorer, which support both Basic and NTLM Authentication, they will respond using the first supported authentication scheme indicated by IIS. On IIS 1.0, when both Basic and NTLM authentication schemes were checked, Basic authentication was listed first. On IIS 2.0, NTLM is now listed before Basic. The result is that for a server running IIS 1.0 using both, Internet Explorer will use Basic authentication. For an IIS 2.0 server using both, Internet Explorer will use NTLM authentication. Many IIS applications access resources provided by other software components. For instance, an ISAPI extension DLL may call an OLE automation server from a third-party software company, or a CGI application. These components may have persistent information stored in the registry that they require in order to execute properly. For standard desktop use of these components, the registry information is read from the profile of the user currently logged on the Windows NT machine. These applications often have problems when launched by IIS because the profile made available to an IIS application is that of the "default user." The default-user profile is filled with information generic to all users, but, unfortunately, is specific to no users. Therefore, a component may run as expected when User1 executes it interactively on his or her desktop because it is reading information from User1's profile in the registry. The same application may not run at all from IIS because it will not have access to User1's profile. This is true even if IIS is impersonating User1's account using Basic or NTLM authentication.

Desktop Issues

The implications of this to IIS applications are that the IIS service has its own desktop. If your IIS application interacts with a desktop in any way (for instance, if it displays a message box), then it will display that message box on a desktop that cannot be seen on the computer's monitor. Similarly, an IIS application will not be able to send or post messages to an application on the interactive desktop. If your IIS application needs to interact with the interactive desktop, then you should use another form of inter-process communication such as named pipes.

ISAPI Filter DLLs

COM and OLE Permissions

The utility DCOMCNFG on Windows NT 4.0 allows you to set the default permissions for *ALL* COM and OLE objects on your machine. You can use this utility to provide OLE and COM access to the IUSR_<servername> account as well as all user accounts that might be impersonated by your IIS configuration. You can even grant permissions to the "Everyone" group.

However, providing global access to all OLE and COM objects may not be in your best interest, so DCOMCNFG will also allow you to specify permissions for specific applications so you could provide access to only the applications you will need to access from your IIS application. OLE and COM applications also have the ability to determine what permissions are associated with launching and accessing themselves. To do this from inside your OLE or COM server, see the CoInitializeSecurity function new to Windows NT 4.0, as well as CoCreateInstanceEx (in particular, the COSERVERINFO and COAUTHINFO structures) for manipulating OLE access from the client side.

Distributed COM (DCOM), also referred to as Remote Automation, requires all of the OLE/COM permissions discussed above. In addition, it needs to access resources across the network. If a request is received using Anonymous authentication, the IUSR_<servername> account username and password credentials will be used to connect to the remote DCOM server. Unless your IIS server machine is also a domain controller, the remote machine by default will not know who the IUSR_<servername> account is (it only exists on the local IIS server machine). Adding access and launch permissions to the group "Everyone" does not help in this case because DCOM will not map access by an unknown account to the guest account in the same way that the Lanman Server service does for file sharing. The DCOM server machine must explicitly know the account that is being used.

To deal with a scenario where you have IIS applications accessing resources (including DCOM resources) on remote machines, you need to have all the machines involved participate in a domain relationship. Then, in Internet Manager, you can change your anonymous account to an account in the local or trusted domain. Now, all machines in the domain structure will recognize the account and can explicitly add/delete access to their network resources for that account or any group that account is a member of.

Be aware that if Basic authentication is used for an IIS request, access to network resources (including DCOM servers) will be done in the context of the user whose credentials were passed with the request. If the user specified does not have permissions to launch or access the DCOM server, the request will fail.

If the IIS request is validated using NTLM authentication, the impersonation level does not imply knowledge of the username and password credentials. Therefore, access to network resources, regardless of the permissions on the resource, will be denied (with the exception of NULL Session resources).

<html>
  <head>
    <title>Experimenting with Relative Paths</title>
  </head>
<body>
  <img src="http://www.matlus.com/images/MatlusTabs_Base.png" border="0" />
</body>
</html>

<img src="/images/MatlusTabs_Base.png" border="0" />

The src attribute is in the form of a relative path. If you navigate to my web site, and take a look at some of the html there, you'll notice that the src attribute of the <img> tags do not contain the domain name as it did earlier. But you still see the images. Now modify the <img> tag in the html page you made earlier to be like that shown above. You'll notice that you don't see an image any more.

I'd like to explain this in terms of how a web browser works. When a browser is pointed to an html page, it retrieves this html page. First all it does is it gets the html (this is what you see when you do a "view source menu option"). It then parses this html. While parsing the html it comes across the <img> tag. It looks at the src attribute. What? No domain? Ok, then I'll just assume the domain is the same domain that the html came from (It resolves the relative path)! But there is no image in this path.

Difference between opening an HTML page by double clicking it and "browsing" to it.

If you double clicked on the html file (the physical file), the browser looks for the image in this case in a sub folder of the folder in which the html file resides. If you have a web server running locally and called this html file using a url such as http://localhost/test.htm then when the browser makes a request on the web server for the image, it expects to find an image in a subfolder (or virtual folder).

You will have noticed relative paths that include the ISAPI dll or CGI exe file name as well. In code, you use the Request.ScriptName property. This results in something like /scripts/myisapi.dll. In this case, you don't want to hard code the name of the application either. It's best using Request.ScriptName. But again, a relative path only makes sense if the ISAPI (in this case) is in the same domain as the web page that uses this relative path.

Virtual folders and the TPageProducer

1. A sub folder of your Web Server's root folder. (C:\inetpub\wwwroot\images in case of IIS)
2. A virtual folder defined in your web server for the web site. This virtual folder has the name "images" but it could be virtually anywhere on the server's hard disk. A network share or an URL.

When creating a virtual folder in IIS, make sure the User name is in the form MACHINENAME\UserName where MACHINENAME is the name of the machine on the network on which the physical folder exists. Just UserName will not work.

If in your environment your development machine's directory structure does not match that of the target production machine, you should create virtual folders on your development machine (and also production machine if need be) that map to the target machine. Never hard code paths in the html that is returned to the browser. Following this rule will go a long way in smoothening out the deployment process while also allowing for changes later, in the production environment.

In Delphi we have this wonderful component called the TPageProducer. We won't go into the details of how to use it here. However, it has a property called HTMLFile. The value of this property is normally the path and name of an html template (a file that has special tags that the Page Producer understands). Now the PageProducer, needs a physical path (not URL) for the physical .htm file. The IUSR_ user needs to have read access to this folder and file.

Lets say you've defined a virtual folder called HTMLTemplates in your WebServer. This virtual folder points to a physical location on your hard drive. You can get the physical path of the virtual folder by using the Request object's TranslateURI method.

If you leave the parameter (to the TranslateURI method) empty, you'll get the physical path to the root folder of your web server (C:\Inetpub\wwwroot in the case of IIS). If you supply '/images' as the parameter you'll get the physical path of the "images" virtual folder. If no such folder exists (that is a virtual folder has not been defined), you'll simply get the word "\images" appended to the web server's root folder path (notice the way the forward slash changes to a back slash for physical paths).

Given this knowledge, you should be able to get your page producer to load an html template from any folder on your web server . Simple code like that shown below works really well and can be used in all your ISAPIs if you follow a trend.

  TWebModule1 = class(TWebModule)
    procedure WebModuleBeforeDispatch(Sender: TObject;
      Request: TWebRequest; Response: TWebResponse; var Handled: Boolean);
  private
    FHTMLTemplatePath: string;
    property HTMLTemplatePath: string read FHTMLTemplatePath;
    { Private declarations }
  public
    { Public declarations }
  end;

var
  WebModule1: TWebModule1;

implementation

{$R *.DFM}

procedure TWebModule1.WebModuleBeforeDispatch(Sender: TObject;
  Request: TWebRequest; Response: TWebResponse; var Handled: Boolean);
begin
  if HTMLTemplatePath = '' then
    FHTMLTemplatePath := Format('%s\',[Request.TranslateURI('/HTMLTemplates')]);
end;

It is assumed here that either you've defined a virtual folder in your web server called HTMLTemplates, or you've got a physical folder under your web server's root folder by this name.

Further, the "scripts" folder generally has "read/execute" access. It is not advisable to keep your html templates in this "kind" of folder. Under W2K, sub folders of this folder automatically inherit the parent folder's property. My advice is that you create a sub folder under your web server's root folder (they will automatically have the correct access rights), or create a folder under inetpub and map a virtual folder to it.

TCP

IP

IP addresses are globally unique, 32-bit numbers assigned by the Network Information Center. Globally unique addresses permit IP networks anywhere in the world to communicate with each other.

An IP address is divided into three parts. The first part designates the network address, the second part designates the subnet address, and the third part designates the host address.

IP addressing supports three different network classes. Class A networks are intended mainly for use with a few very large networks, because they provide only 8 bits for the network address field. Class B networks allocate 16 bits, and Class C networks allocate 24 bits for the network address field. Class C networks only provide 8 bits for the host field, however, so the number of hosts per network may be a limiting factor. In all three cases, the leftmost bit(s) indicate the network class. IP addresses are written in dotted decimal format; for example, 24.28.0.1

Ports and Sockets

1. An application process is assigned a process identifier (process ID) which is likely to be different each time that process is started.
2. Process IDs differ between each operating system platforms, hence they are not uniform.
3. A server process can have multiple connections to multiple clients at a time, hence simple connection identifiers would not be unique.

Ports

Well-Known Ports

Ephemeral Ports

I personally am totally in love with this technology. It is VERY powerful and has opened up the whole world to me (literally). Today, I understand a lot of what is going on and how it's done, primarily because I now understand TCP/IP. In the short time that I've been playing around with TCP/IP, I have done some really wonderful things with it. Let's get down to it..

For this protocol to work there has to be a client and a server socket. A socket is referred to as an end point. An application that contains a client socket is called a client while an application that contains a server socket is called a server. The client establishes a connection with the server and once this connection is established data can be transferred from the client to the server or server to client (Also known as full duplex) over the same connection. For a connection to be established the client needs to know the IP address and a port number (also known as a SOCKET).

TCP/IP is a connection-oriented protocol. Data is transferred from one socket to the other in the form of bytes. The TCP/IP protocol guarantees that all data sent will be received (as long as a connection is maintained). It does not guarantee however that the data will be received in the way it was sent. But it does guarantee that the data will be received in the order in which it was sent.

Let me explain the above a bit more with some example. Let's say we have a client application and a server application that have established a connection. Let's say that we send the string "Borland" and then "Delphi" from the client to the server. Just because you first sent the string "Borland" and later sent the string "Delphi", does not mean that the server gets it as two packets. The server will receive all the data, but not as you sent it. It could receive it all in one packet (BorlandDelphi) or in any combination. Even one byte at a time! Only the order is guaranteed and what was sent will be received. The time it takes and the way it is received all depends on the network speed and traffic.

Seeing this possibility, one generally has to devise ones own protocol "on top of" the TCP/IP protocol. The simplest thing one could do is, transmit every string with an ending carriage return and line feed. Then on the server side, you break up the bytes received by scanning for a carriage return and line feed combination. So you will then know that the string "Borland" was sent and then the string "Delphi" was sent. You will always define your own "protocol" when working with TCP/IP for this reason. Some protocols that have already been defined are HTTP, SMTP, POP, FTP etc. These are standards. An HTTP Client (Browser) knows how to "talk" to an HTTP server (web server) since the protocol is a standard. Therefore you can use any browser with any web server.

Lets look at a real example of this. To try this example, you will need:

1. A connection to the Internet.
2. The IP address or host name of your POP3 server.
3. Your user name /account for this server.
4. Your password for the account.
5. A telnet client. (Win95/98/NT has a telnet client).

Lets say, my email address is shivk@erols.com

Generally, the POP3 server name is - pop.erols.com. (or pop3.erols.com or even erols.com)

The port POP3 uses is 110. (its a standard)

The user name is shivk

Let's say my password is delphi.

I'll use the telnet client that comes with win95/98/NT for this example.

1. Choose Start | Run from the task bar and type - telnet and then click OK.
2. From the telnet client's Connect menu choose - Remote System.
3. Type in your POP3 server name in the Host Name field. (pop.erols.com)
4. Type in 110 in the port field.
5. Click OK.
6. The telnet client will connect to your POP3 server and you should see a response from the server. The POP3 protocol says that a POP3 server should respond with a " OK". What you see after the first 4 characters is dependent on the server application.
7. In the telnet screen type the words - user shivk and press the Enter key.(use your account name instead of - shivk).
8. Again, if you typed it correctly, you should see that the server responds with a " OK".
9. Next type - pass delphi and press the Enter key (use your password instead of - delphi).
10. The server should respond with a " OK" once again.
11. You have now logged into you email server directly. This is what your email client does for you.
12. Next type in - list and press the Enter key..
13. The server should respond with a " OK" and the number of messages and their sizes.
14. If you have any messages, type in - retr 1 and press the Enter key (1 is the first message).
15. You should see the first email that the server has waiting for you. This email will contain the full header as well as the message itself.
16. If you want to Delete this message, you would type Dele 1. I suggest you DON'T do this !

As another example, I have built a VERY simple TCP/IP server that is running on my PC. I've established a certain protocol that you need to use to communicate with it. Use the same telnet client for this.

The host name is www.matlus.com

The port is 3232.

Basically, it will respond with whatever you send it, along with a " OK" and your IP address and the date and time on my PC at the time of responding.

A "command" it understands is - About. See what happens when you type in the word - about.

This server is also capable of sending back information from a database. The TQuery component is connected to the DBDEMOS Alias. To fire a query on the server the command is SQL: followed by the SQL statement you want it to execute. So if you wanted to see all records of the table, you type:

SQL: SELECT * FROM CUSTOMER

Any valid SQL statement is allowed. You will also notice that the first line returned is the fields names. And also, that each field is delimited by a special character #0183 and that each line is delimited with #1086. I've chosen these just because I like them ! This is my Protocol

This will come in handy when we build the client application for this server (rather than use telnet).

If you want to join a list server dedicated to this tutorial, have a look at my List Server link.

If you liked this article and would like to see more, please let me know.email me