web server
Enable an agent to recognise a web-serving host, assess its ability to serve intended HTTP requests, and determine which operational actions are authorised.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
recalled by Codex without web access - no source was read
Researched by: Codex
Purpose and description
Enable an agent to recognise a web-serving host, assess its ability to serve intended HTTP requests, and determine which operational actions are authorised.
A web server, in the physical-object sense, is a computer configured to run software that accepts HTTP requests from clients and returns responses containing web resources, application results, or status information.
It can be Inspect host-to-service relationships and test HTTP behaviour for a specified hostname, route and network vantage point.; Trace a request through local routing, TLS termination, content delivery and application upstreams.; Compare observed demand and resource headroom against documented service targets.; Validate and apply authorised listener, route, content or certificate changes with a defined rollback.; Drain traffic, reload or restart the relevant service when authorised and operationally supported.; Diagnose failures and verify restoration using representative requests and dependency checks..
Distinguishing features
The host has an assigned HTTP-serving role supported by configuration or deployment evidence; an installed but unused server package alone does not establish that role.
Its configured listeners can receive HTTP requests and produce or relay HTTP responses when the required dependencies are available; TCP reachability alone does not demonstrate web serving.
The physical host is distinguishable from the server executable, deployment instance and hosted website through separate identities and relationships.
A reverse-proxy-only host may qualify, but its forwarding role must be distinguished from originating static content or executing application requests.
A host running only a database, file-sharing service or unrelated network service does not qualify unless a web-serving role is also established.
Scope
+ Physical host identity and assignment to a web-serving role
+ HTTP listeners, network reachability and request routing
+ Relationships to server software, hosted sites, content and application upstreams
+ Transport security, administrative control and request-handling restrictions
+ Resource capacity, service health, maintenance and recovery
- HTTP server software packages as independently versioned software products
- Website content, editorial meaning and application business logic
- Browsers and other HTTP clients
- DNS infrastructure, certificate authorities and external network infrastructure
- Complete hosting platforms, server fleets and distributed delivery services
- Virtual machines and containers as independently managed computing resources
Characteristics
- Host identity and deployment relationships
- Physical asset identifier linked to operating-system instances, virtual machines, containers and HTTP-serving processes where applicable Prevents a host, a software process and a website from being treated as the same entity.
- Web-serving role
- Static origin, application gateway, reverse proxy, caching proxy, or documented combination Determines which requests the host handles locally and which depend on other services.
- Listener configuration
- Bind address, transport, port, HTTP protocol configuration and TLS termination point Identifies how requests enter the service and where connection failures can occur.
- Hosted authority and route mappings
- Hostnames and path rules linked to virtual hosts, document roots or upstream services Establishes which site or application a request should reach.
- Observed service state
- Unverified, serving, degraded, draining, stopped or unreachable; qualified by observation time and vantage point Separates operational evidence from configuration and avoids equating one failed probe with host failure.
- Request throughput
- Requests/s, with workload, response mix and observation interval Supports capacity assessment without treating unlike workloads as equivalent.
- Response latency
- Milliseconds at stated percentiles, with measurement boundary and request class Shows whether representative requests meet the service's performance expectations.
- Request outcomes
- Counts or proportions of HTTP status classes, timeouts and connection failures over a stated interval Distinguishes successful delivery, rejected requests and failures that produce no HTTP response.
- Resource headroom
- CPU utilisation %, available RAM bytes, free storage bytes, network bit/s and active connections relative to configured limits Helps locate saturation and determine whether additional load or maintenance is tolerable.
- Transport protection
- Plain HTTP, TLS terminated locally, TLS terminated upstream, or mixed; with certificate and protocol configuration references Identifies which connection segments are protected and who controls that protection.
- Operational authority
- Owners and permitted principals linked to inspect, deploy, reload, restart, drain and retire actions Makes technical capability distinct from permission to act.
Also called
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 6 bundles · 11 layers · 18 findings · 28 questions.
Host and web-serving identity Establishes the physical entity and the web-serving responsibilities assigned to it.
Web server can name hardware, software or a service; the model must make its chosen entity and role inspectable.
Physical host boundary
Connects the registered physical kind to identifiable hosts and their execution environments.
Host-to-runtime assignment
Record evidence linking a physical host to the environments and processes that perform web serving.
- Which physical asset is being described, and which operating-system instances, virtual machines or containers run its HTTP-serving processes? boundary
- Which inventory or deployment record establishes that assignment, and when was it last verified? provenance
Serving role and tenancy
Identifies what the host serves and how distinct hosted services share it.
Origin, proxy and site responsibilities
Record whether the host originates responses, forwards requests, caches responses or combines these roles for particular sites.
- For each hosted service, does this host serve files, invoke application code, forward requests or return cached responses? definition
- Which sites or tenants share this host, and which resources or configuration changes can affect more than one of them? boundary
HTTP ingress and routing Describes how requests reach the host and select a destination.
An active server process does not establish that the intended client can reach the correct site.
Listeners and reachability
Records exposed listeners and the network paths through which they are available.
Reachable HTTP endpoints
Record configured endpoints separately from observed reachability through firewalls, address translation and external front ends.
- Which addresses, transports, ports and HTTP protocol configurations accept requests, and which are intended to be publicly reachable? definition
- From which client locations have the intended endpoints been tested, and what response or connection failure was observed? measurement
Authority and path dispatch
Explains selection of virtual hosts, routes and upstream destinations.
Request destination selection
Record how hostname, TLS server-name selection where applicable, and path rules determine the request destination.
- How do the requested hostname and path select a virtual host, document root, redirect or upstream? definition
- What happens for an unknown hostname, unmatched path or inconsistent TLS server name and HTTP authority? boundary
Response production and dependencies Captures how the host obtains response data and what it requires to deliver it.
Correct HTTP handling depends on content mappings, application availability and response transformations.
Content and application bindings
Connects request routes to files, applications and external dependencies.
Response source binding
Record the source of responses and the credentials, permissions and dependencies needed to obtain them.
- Which filesystem locations or application endpoints provide responses for each route, and under which service identity are they accessed? boundary
- Which request checks demonstrate that required content and upstream services are available through the web server? measurement
Response policy and upstream failure
Records caching, transformation and failure behaviour relevant to delivered responses.
Delivery and fallback rules
Record configured cache behaviour, compression, upstream timeouts and error handling without assuming they are enabled.
- Which responses may be cached or compressed, and what determines cache keys, freshness and invalidation? definition
- What response is produced when an upstream is slow or unavailable, and under what conditions may a request be retried? action
Transport trust and access Describes connection protection, exposed capabilities and authority over the server.
A functioning web endpoint can still expose unintended content, trust unverified request metadata or permit unauthorised changes.
TLS and proxy trust
Locates encryption boundaries and identifies trusted intermediaries.
Connection protection boundaries
Record TLS termination, certificate responsibility and the rules for trusting metadata supplied by proxies.
- Where does TLS terminate on each request path, which names must the certificate cover, and who manages renewal? boundary
- Which intermediaries may supply trusted client-address or scheme information, and how is that trust restricted? definition
Request and administration controls
Separates public request permissions from privileges to operate the host and service.
Permitted exposure and changes
Record access restrictions, request limits and operational permissions for the web-serving deployment.
- Which methods, paths, upload sizes and request rates are permitted, and where are authentication and access checks enforced? definition
- Which principals may change routes, read logs, deploy content, replace certificates or restart services, and what approval conditions apply? action
Capacity, health and recovery Connects request-level performance to host resources and operational recovery.
The model must distinguish a responsive process from a service that can meet demand and survive maintenance or failure.
Request health and host headroom
Relates representative HTTP outcomes to resource constraints and physical operating conditions.
Observed serving capacity
Record workload-qualified performance alongside resource saturation and relevant power, cooling or hardware alerts.
- For which request mix and observation window are throughput, latency, error rate and concurrent connections measured against a service target? measurement
- Do CPU, memory, storage, connection limits, network utilisation or power and thermal alerts explain the observed degradation? measurement
Safe change and restoration
Defines how service changes and failures are handled with evidence of successful recovery.
Validated maintenance and recovery
Record configuration validation, traffic draining, rollback and restoration procedures for the actual hosting arrangement.
- How are configuration changes validated and rolled back, and how are active requests or long-lived connections handled during reload, restart or host maintenance? action
- Which configuration, content, secrets and external dependencies are needed to restore serving, and which representative requests verify recovery? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.
A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.
Reported evidence
Findings from the breadth pass, kept separate from the structural claims.
Check these first
Recalled without web access and unsourced; every item is a lead to verify.
- The term commonly denotes software as well as hardware; the physical sense is selected here because the supplied domain is PHY.OBJ.
- The listed protocol standards apply to implemented capabilities; a web server need not support every HTTP version.
- No typical capacity, dimensions, power consumption, or throughput range is supplied because embedded devices and data-centre systems differ substantially.
- Which of these check these first hold for the sense of web server this model covers, and on what evidence? provenance
Kinds and varieties
Recalled without web access and unsourced; every item is a lead to verify.
- Dedicated physical web server
- Shared-purpose computer hosting a web service
- Embedded web server in a device
- Which of these kinds and varieties hold for the sense of web server this model covers, and on what evidence? provenance
Identifiers and schemes
Recalled without web access and unsourced; every item is a lead to verify.
- Manufacturer serial number - Manufacturer-assigned alphanumeric identifier - Identifies a physical unit, not the websites or services it hosts.
- Domain Name System (DNS) - Dot-separated domain labels - Names a service endpoint; one name may resolve to multiple servers, and one server may host multiple names.
- Internet Protocol addressing - IPv4 or IPv6 address - Identifies a network interface or reachable endpoint, not a permanent physical-unit identity.
- Which of these identifiers and schemes hold for the sense of web server this model covers, and on what evidence? provenance
Standards and regulation
Recalled without web access and unsourced; every item is a lead to verify.
- IETF RFC 9110, HTTP Semantics.
- IETF RFC 9112, HTTP/1.1.
- IETF RFC 9113, HTTP/2.
- IETF RFC 9114, HTTP/3.
- IETF RFC 8446, Transport Layer Security (TLS) 1.3.
- Which of these standards and regulation hold for the sense of web server this model covers, and on what evidence? provenance
Real-world use
Recalled without web access and unsourced; every item is a lead to verify.
- Serving websites and downloadable files.
- Hosting web applications and HTTP APIs.
- Providing browser-based administration for routers, printers, and other devices.
- Hosting internal organisational portals.
- Terminating HTTPS connections and forwarding requests to application services.
- Which of these real-world use hold for the sense of web server this model covers, and on what evidence? provenance
Failure modes and hazards
Recalled without web access and unsourced; every item is a lead to verify.
- Power, cooling, storage, or network failures interrupt service.
- Traffic surges or denial-of-service attacks exhaust connection, processing, memory, or bandwidth capacity.
- Software vulnerabilities or configuration errors permit unauthorised access, data exposure, or code execution.
- Expired certificates or incorrect TLS configuration prevent secure connections.
- Application or upstream-service failures produce errors, timeouts, or incorrect responses.
- Which of these failure modes and hazards hold for the sense of web server this model covers, and on what evidence? provenance
Regional variation
Recalled without web access and unsourced; every item is a lead to verify.
- Privacy, logging, and data-residency obligations depend on jurisdiction and the data processed.
- Mains power, plug types, and applicable electrical and electromagnetic-compatibility requirements vary by deployment region.
- Which of these regional variation hold for the sense of web server this model covers, and on what evidence? provenance
Neighbouring kinds and how to tell them apart
Recalled without web access and unsourced; every item is a lead to verify.
- Web server software - The program implements HTTP handling; the physical web server is the computer running it.
- Application server - Its defining role is executing application logic; a web server's defining role is handling HTTP requests, although one system can do both.
- Website - A website is a collection of related web resources and experiences, rather than the computer that serves them.
- Reverse proxy - A reverse proxy primarily forwards client requests to upstream servers; a web server may serve resources directly or also perform that proxy role.
- Virtual server - A virtual server is a software-defined computing instance rather than a distinct physical computer.
- Which of these neighbouring kinds and how to tell them apart hold for the sense of web server this model covers, and on what evidence? provenance
What the second pass must settle
- Does the registry intend the physical host sense adopted here, the HTTP server software sense, or a broader service sense despite its PHY / PHY.OBJ assignment?
- Does an existing Vercy world model already cover this concept, requiring a registry link instead of a separate publication?
- Should a physical host with only an incidental embedded management web interface qualify, or must web serving be an explicitly assigned operational role?
- Which HTTP, TLS and deployment-specific standards and versions should be cited after primary-source research, and which requirements apply to each serving role?
- Which representative workloads, availability objectives and recovery targets should be used to judge state without inventing universal capacity thresholds?