feat(routes): add protocol-based route matching and ensure terminate-and-reencrypt routes HTTP through the full HTTP proxy; update docs and tests

readme.md

@@ -27,7 +27,7 @@ Whether you're building microservices, deploying edge infrastructure, or need a
 | 🦀 **Rust-Powered Engine** | All networking handled by a high-performance Rust binary via IPC |
 | 🔀 **Unified Route-Based Config** | Clean match/action patterns for intuitive traffic routing |
 | 🔒 **Automatic SSL/TLS** | Zero-config HTTPS with Let's Encrypt ACME integration |
-| 🎯 **Flexible Matching** | Route by port, domain, path, client IP, TLS version, headers, or custom logic |
+| 🎯 **Flexible Matching** | Route by port, domain, path, protocol, client IP, TLS version, headers, or custom logic |
 | 🚄 **High-Performance** | Choose between user-space or kernel-level (NFTables) forwarding |
 | ⚖️ **Load Balancing** | Round-robin, least-connections, IP-hash with health checks |
 | 🛡️ **Enterprise Security** | IP filtering, rate limiting, basic auth, JWT auth, connection limits |
@@ -89,7 +89,7 @@ SmartProxy uses a powerful **match/action** pattern that makes routing predictab
 ```
 
 Every route consists of:
-- **Match** — What traffic to capture (ports, domains, paths, IPs, headers)
+- **Match** — What traffic to capture (ports, domains, paths, protocol, IPs, headers)
 - **Action** — What to do with it (`forward` or `socket-handler`)
 - **Security** (optional) — IP allow/block lists, rate limits, authentication
 - **Headers** (optional) — Request/response header manipulation with template variables
@@ -103,7 +103,7 @@ SmartProxy supports three TLS handling modes:
 |------|-------------|----------|
 | `passthrough` | Forward encrypted traffic as-is (SNI-based routing) | Backend handles TLS |
 | `terminate` | Decrypt at proxy, forward plain HTTP to backend | Standard reverse proxy |
-| `terminate-and-reencrypt` | Decrypt, then re-encrypt to backend | Zero-trust environments |
+| `terminate-and-reencrypt` | Decrypt at proxy, re-encrypt to backend. HTTP traffic gets full per-request routing (Host header, path matching) via the HTTP proxy; non-HTTP traffic uses a raw TLS-to-TLS tunnel | Zero-trust / defense-in-depth environments |
 
 ## 💡 Common Use Cases
 
@@ -135,13 +135,13 @@ const proxy = new SmartProxy({
       ],
       {
         tls: { mode: 'terminate', certificate: 'auto' },
-        loadBalancing: {
-          algorithm: 'round-robin',
-          healthCheck: {
-            path: '/health',
-            interval: 30000,
-            timeout: 5000
-          }
+        algorithm: 'round-robin',
+        healthCheck: {
+          path: '/health',
+          interval: 30000,
+          timeout: 5000,
+          unhealthyThreshold: 3,
+          healthyThreshold: 2
         }
       }
     )
@@ -318,6 +318,42 @@ const proxy = new SmartProxy({
 
 > **Note:** Routes with dynamic functions (host/port callbacks) are automatically relayed through the TypeScript socket handler server, since JavaScript functions can't be serialized to Rust.
 
+### 🔀 Protocol-Specific Routing
+
+Restrict routes to specific application-layer protocols. When `protocol` is set, the Rust engine detects the protocol after connection (or after TLS termination) and only matches routes that accept that protocol:
+
+```typescript
+// HTTP-only route (rejects raw TCP connections)
+const httpOnlyRoute: IRouteConfig = {
+  name: 'http-api',
+  match: {
+    ports: 443,
+    domains: 'api.example.com',
+    protocol: 'http',   // Only match HTTP/1.1, HTTP/2, and WebSocket upgrades
+  },
+  action: {
+    type: 'forward',
+    targets: [{ host: 'api-backend', port: 8080 }],
+    tls: { mode: 'terminate', certificate: 'auto' }
+  }
+};
+
+// Raw TCP route (rejects HTTP traffic)
+const tcpOnlyRoute: IRouteConfig = {
+  name: 'database-proxy',
+  match: {
+    ports: 5432,
+    protocol: 'tcp',    // Only match non-HTTP TCP streams
+  },
+  action: {
+    type: 'forward',
+    targets: [{ host: 'db-server', port: 5432 }]
+  }
+};
+```
+
+> **Note:** Omitting `protocol` (the default) matches any protocol. For TLS routes, protocol detection happens *after* TLS termination — during the initial SNI-based route match, `protocol` is not yet known and the route is allowed to match. The protocol restriction is enforced after the proxy peeks at the decrypted data.
+
 ### 🔒 Security Controls
 
 Comprehensive per-route security options:
@@ -549,6 +585,7 @@ interface IRouteMatch {
   clientIp?: string[];                 // ['10.0.0.0/8', '192.168.*']
   tlsVersion?: string[];               // ['TLSv1.2', 'TLSv1.3']
   headers?: Record<string, string | RegExp>;  // Match by HTTP headers
+  protocol?: 'http' | 'tcp';          // Match specific protocol ('http' includes h2 + WebSocket upgrades)
 }
 ```