Start a native web server

Use the native BWS APIs when your application serves files or handles HTTP requests in C or C++. The same native APIs are available in BAS. A typical server joins a dispatcher, a server object, a listener, and a tree of routes.

Before you build

Use a matching SDK/library, target headers, compiler, and network/thread port. Follow the SDK's example build setup and Configure BAS and BWS for Your Product. The examples can require CSP tools and generated resources in addition to a C/C++ compiler.

Read the C/C++ API mapping. C functions normally take the object pointer as their first argument; C++ wrappers supply that pointer through this. Follow API contracts rather than accessing structure fields directly.

Follow the supplied introduction

The CSP introduction example provides a native server and browser-accessible request handlers. Its examples/introduction/src/start.c shows server startup and src/InstallVD.c installs the routes. This is the first complete project to build; it is not a single-file example.

1. Complete the SDK example build setup linked above.
2. Build the introduction project for the configured platform. The source tree includes VcMake/example.sln and make/Makefile; use the build environment described by your SDK.
3. Start the generated demo executable. With tracing enabled, the shared examples/misc/OpenSocketCon.h helper reports HTTP: Server listening and the selected port. Open http://127.0.0.1:PORT/ on the same computer, replacing PORT with that value. An unmodified debug build first tries
   1. Other builds first try HTTP_PORT, if defined, or port 80. If that attempt fails, the helper tries ports 9357 through 9369.
4. Follow the example pages, then set a breakpoint in a request handler and follow one request from the browser.

Understand the object sequence

Stage	Objects and responsibilities
Prepare the port	Initialize the target's networking and threading prerequisites.
Create the dispatcher	Keep its ThreadMutex and SoDisp alive throughout server use.
Configure the server	Optionally initialize HttpServerConfig, then construct HttpServer. Configuration is consumed during construction.
Install routes	Use HttpDir/HttpPage for handlers, or HttpResRdr with an IoIntf for files. Retain borrowed resources and names for the documented lifetime.
Open a listener	Use HttpServCon for HTTP or HttpSharkSslServCon for HTTPS and handle listener setup failures.
Dispatch requests	Run the port's dispatcher loop and use the server mutex when accessing its objects from other threads.
Shut down	Stop incoming work and worker activity before destruction. Retain callback dependencies through cleanup; release borrowed port objects afterward.

This sequence explains the roles; the supplied startup source and each API contract define the exact calls and target-specific requirements. See The SoDisp mutex. for locking and HTTP Engine and Sockets for pool sizing.

Add one capability at a time

Choose Filesystems and I/O for files, Authentication and authorization for protected routes, WebSockets for browser messaging, and JSON and UBJSON for structured data. The Native integration examples catalog maps these tasks to supplied projects.