Web Server
The Web Server is a system-level component inside LOPs that provides a centralized HTTP server for the entire LOPs environment. Rather than each operator running its own server, operators register themselves as services on specific URL path prefixes, and the Web Server routes incoming requests to the correct handler. This keeps port usage minimal and gives every web-facing LOPs service a single, shared entry point.
How It Works
Section titled “How It Works”The Web Server uses TouchDesigner’s built-in Web Server DAT to listen for HTTP requests. When a request arrives, it matches the URI against registered service paths and forwards the request to the matching service’s HandleWebData method. CORS headers are added automatically so browser-based frontends can communicate with TouchDesigner without cross-origin issues.
Services register dynamically at runtime. For example, when a Chat Viewer LOP initializes, it registers a unique path like /chat_viewer_abc123/ with the Web Server. All requests under that path are then routed to that specific Chat Viewer instance.
If only one chat viewer service is registered and a request arrives at the root path /, the Web Server automatically redirects to that viewer for convenience.
Key Features
Section titled “Key Features”- Path-based routing that supports multiple simultaneous services on a single HTTP port
- Automatic CORS headers for browser access (allows GET, POST, and OPTIONS)
- JSON request/response handling for POST data
- Graceful error responses with status codes (400, 404, 500) and descriptive messages
- WebSocket pass-through support for real-time communication
- Service introspection to list all currently registered paths and their owner components
Service Registration
Section titled “Service Registration”Operators that need web access do not interact with the Web Server directly through the parameter panel. Instead, they register programmatically during their initialization. The Web Server maintains an internal registry mapping path prefixes to service handler objects.
Each registered service must implement a HandleWebData method. When a matching request arrives, the Web Server strips the path prefix, packages the request details, and calls that method on the registered service.
Troubleshooting
Section titled “Troubleshooting”- “No service registered for path” (404): The requested URL does not match any registered service. This typically means the operator that owns that path has not initialized yet or has been removed. The error response includes a list of all currently available paths.
- “Invalid JSON” (400): A POST request was received with a body that could not be parsed as JSON. Verify that the client is sending valid JSON with the correct
Content-Typeheader. - “Extension Not Available” (500): The Web Server DAT callback could not find the WebServerEXT extension. This usually means LOPs is still loading or the Web Server component was not initialized properly. Wait for LOPs to finish loading and try again.
- “Service has no HandleWebData method” (500): A service registered itself but does not implement the expected handler method. This indicates a bug in the registering operator.