{"schema":"https://ver.cy/schemas/card/1.0.0","id":"vr.tr.http","code":"thing-q8777","url":"https://ver.cy/models/thing/q8777/","name":"HTTP","alternateNames":["Secure Hypertext Transfer Protocol","HTTPS"],"kind":"thing","status":"published","version":"0.1.0-research.1","language":"en","classifiers":{"family":"Thing Registry","category":"Information and virtual systems","entryKind":"thing","plane":"INF","domain":["INF.KNW"],"industry":[],"navPath":"","tags":[],"facets":{}},"whatItIs":"HTTP is a generic, stateless, application-layer request/response protocol that transfers representations of URI-identified resources using self-descriptive messages, with version-specific mappings onto TCP (HTTP/1.x), a binary framed layer over TCP with or without TLS (HTTP/2), or QUIC (HTTP/3), as defined by the IETF HTTP specifications centred on RFC 9110.","purpose":"Enable an AI agent to recognise HTTP interactions, assess their semantic and operational state, and determine which requests, retries, reuse and forwarding actions are justified.","scope":{"in":["Request methods, target URIs, fields and response status semantics","Representation metadata, content negotiation and message content","Conditional requests, partial transfers and cache reuse","HTTP versions, message framing, streams and intermediary behaviour","Protocol-level evidence governing authentication, redirection, retries and completion"],"out":["Application-specific resource schemas, business rules and transaction guarantees","DNS resolution and domain ownership","TCP and QUIC transport internals","TLS cryptography, certificate lifecycle and trust administration","Browser document rendering, JavaScript execution and browser policy configuration","Service deployment, infrastructure capacity and organisational access governance"],"boundaries":[]},"distinguishingFeatures":["An interaction uses HTTP method and status semantics; carrying bytes over TCP or QUIC alone does not make it HTTP.","An HTTPS URI identifies HTTP communication secured through TLS, rather than a separate application semantics model.","HTTP can carry many representation formats; HTML or JSON content alone does not identify the protocol.","HTTP does not require REST architectural constraints, and a REST claim does not establish which HTTP semantics an API honours.","HTTP/1.1, HTTP/2 and HTTP/3 share core semantics while differing in message encoding and connection or stream handling; textual start lines are not a universal recognition test."],"structure":{"bundles":[{"id":"request-intent-and-resource","name":"Request intent and resource","description":"Records which resource an HTTP request addresses and what its method asks the recipient to do.","layers":[{"id":"target-and-authority","name":"Target and authority","description":"Distinguishes the target URI and authority from the peer or intermediary receiving the message.","findings":[{"id":"effective-request-target","name":"Effective request target","description":"Record the target URI and the evidence used to establish its scheme, authority and resource identifier.","questions":[{"text":"Which URI is targeted, and how do the request-target form, authority fields or pseudo-fields establish it?","id":"effective-request-target-q01","kind":"definition"},{"text":"Is the contacted peer the origin server, a forward proxy, a gateway or a tunnel endpoint?","id":"effective-request-target-q02","kind":"boundary"}]}]},{"id":"method-and-effect","name":"Method and effect","description":"Separates standard method properties from observed or documented application behaviour.","findings":[{"id":"method-semantics-and-guarantees","name":"Method semantics and guarantees","description":"Record the method's defined semantics, safety and idempotency, together with evidence of any application-specific guarantees or deviations.","questions":[{"text":"What does this method request, and are its safety and idempotency properties defined by an applicable specification?","id":"method-semantics-and-guarantees-q01","kind":"definition"},{"text":"What evidence supports the expected effects at this resource, including any request-content semantics or restrictions?","id":"method-semantics-and-guarantees-q02","kind":"provenance"}]}]}]},{"id":"responses-and-representations","name":"Responses and representations","description":"Records what a response means and how its content relates to a selected representation.","layers":[{"id":"status-and-response-sequence","name":"Status and response sequence","description":"Interprets informational and final responses in the context of the originating request.","findings":[{"id":"response-meaning","name":"Response meaning","description":"Record the response sequence and distinguish HTTP-level outcomes from application results requiring separate evidence.","questions":[{"text":"Which responses are informational, which is final, and what does the final status mean for this request method?","id":"response-meaning-q01","kind":"definition"},{"text":"What remains unproven about the application outcome, particularly for accepted processing, absent content or an interrupted response?","id":"response-meaning-q02","kind":"boundary"}]}]},{"id":"content-and-negotiation","name":"Content and negotiation","description":"Connects representation metadata and selection criteria to the content actually exchanged.","findings":[{"id":"selected-representation","name":"Selected representation","description":"Record declared representation properties, negotiation inputs and any mismatch between metadata and observed content.","questions":[{"text":"Which media type, content coding and language are declared, and what evidence confirms or contradicts those declarations?","id":"selected-representation-q01","kind":"measurement"},{"text":"Which request preferences influenced representation selection, and is content expected or permitted for this method and status?","id":"selected-representation-q02","kind":"boundary"}]}]}]},{"id":"caching-and-conditional-transfer","name":"Caching and conditional transfer","description":"Records when an HTTP response can be reused and how validators or ranges constrain subsequent transfers.","layers":[{"id":"stored-response-reuse","name":"Stored response reuse","description":"Evaluates storage and reuse in the context of a private or shared cache.","findings":[{"id":"cache-selection-and-freshness","name":"Cache selection and freshness","description":"Record cache context, matching criteria, directives, age and freshness evidence before reusing a response.","questions":[{"text":"May this cache store and reuse the response, considering its private or shared role, method, status and applicable directives?","id":"cache-selection-and-freshness-q01","kind":"action"},{"text":"Do the target, method and Vary-selected request fields match, and what calculated age and freshness lifetime govern reuse?","id":"cache-selection-and-freshness-q02","kind":"measurement"}]}]},{"id":"validators-preconditions-and-ranges","name":"Validators, preconditions and ranges","description":"Uses representation validators to condition operations and assess partial transfers.","findings":[{"id":"conditional-operation","name":"Conditional operation","description":"Record available entity tags or modification dates, their comparison requirements, and the intended role of preconditions or ranges.","questions":[{"text":"Which validators are available, and does the proposed precondition require a strong or weak comparison?","id":"conditional-operation-q01","kind":"definition"},{"text":"Which conditional fields would validate a cached response or guard an update, and how should a 304 or 412 response change the next action?","id":"conditional-operation-q02","kind":"action"},{"text":"If a range is requested, what supports range handling and representation continuity, and how will 206, 416 or a full response be handled?","id":"conditional-operation-q03","kind":"action"}]}]}]},{"id":"messaging-path-and-completion","name":"Messaging path and completion","description":"Records version-specific message boundaries, intermediary transformations and evidence of exchange completion.","layers":[{"id":"version-framing-and-intermediaries","name":"Version, framing and intermediaries","description":"Relates shared HTTP semantics to the encoding and forwarding rules used on each observed hop.","findings":[{"id":"message-boundaries-and-forwarding","name":"Message boundaries and forwarding","description":"Record the HTTP version, framing evidence and known intermediary changes without assuming end-to-end wire equivalence.","questions":[{"text":"Which HTTP version is observed on each known hop, and what establishes the end of the message content and any trailers?","id":"message-boundaries-and-forwarding-q01","kind":"measurement"},{"text":"Could conflicting length indicators, invalid fields or intermediary transformations cause different recipients to interpret different message boundaries?","id":"message-boundaries-and-forwarding-q02","kind":"boundary"}]}]},{"id":"failure-and-retry","name":"Failure and retry","description":"Separates transport or stream failure from knowledge of whether the requested operation took effect.","findings":[{"id":"completion-evidence-and-repetition","name":"Completion evidence and repetition","description":"Record how far the exchange progressed and what evidence justifies repeating it.","questions":[{"text":"What evidence shows whether the request was transmitted, processed or answered completely, and where does the outcome remain unknown?","id":"completion-evidence-and-repetition-q01","kind":"measurement"},{"text":"Do method semantics, a version-specific failure signal or a documented application guarantee justify a retry, and what timing guidance applies?","id":"completion-evidence-and-repetition-q02","kind":"action"}]}]}]},{"id":"credentials-and-follow-up-boundaries","name":"Credentials and follow-up boundaries","description":"Records HTTP authentication and routing signals that affect the authority and scope of subsequent requests.","layers":[{"id":"authentication-and-state-context","name":"Authentication and state context","description":"Distinguishes origin authentication, proxy authentication and application state carried in HTTP fields.","findings":[{"id":"credential-recipient-and-scope","name":"Credential recipient and scope","description":"Record challenges and credential or cookie scope through references that avoid retaining secret values unnecessarily.","questions":[{"text":"Does the response challenge origin authentication or proxy authentication, and which scheme and protection space does it identify?","id":"credential-recipient-and-scope-q01","kind":"definition"},{"text":"Which credentials or cookies may accompany the next request, based on recipient scope, applicable client policy and the agent's existing authority?","id":"credential-recipient-and-scope-q02","kind":"action"}]}]},{"id":"redirects-and-protocol-transitions","name":"Redirects and protocol transitions","description":"Evaluates changes to the request destination, method or communication mode.","findings":[{"id":"follow-up-request-boundary","name":"Follow-up request boundary","description":"Record what a redirect, successful CONNECT or protocol upgrade proposes and which semantics continue to apply.","questions":[{"text":"For a redirect, how is Location resolved, what method and content behaviour applies, and does the destination change origin or scheme?","id":"follow-up-request-boundary-q01","kind":"action"},{"text":"If a tunnel or protocol upgrade is established, where does ordinary HTTP message interpretation stop and the neighbouring protocol model take over?","id":"follow-up-request-boundary-q02","kind":"boundary"}]}]}]},{"id":"evidence-and-external-alignment","name":"Evidence and external alignment","description":"What the world already says about this thing, gathered so the model can be checked against it.","layers":[{"id":"reported-evidence","name":"Reported evidence","description":"Findings from the breadth pass, kept separate from the structural claims.","findings":[{"id":"evidence-kinds","name":"Kinds and varieties","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these kinds and varieties hold for the sense of HTTP this model covers, and on what evidence?","id":"evidence-kinds-q01","kind":"provenance"}]},{"id":"evidence-identifiers","name":"Identifiers and schemes","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these identifiers and schemes hold for the sense of HTTP this model covers, and on what evidence?","id":"evidence-identifiers-q01","kind":"provenance"}]},{"id":"evidence-standards-and-regulation","name":"Standards and regulation","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these standards and regulation hold for the sense of HTTP this model covers, and on what evidence?","id":"evidence-standards-and-regulation-q01","kind":"provenance"}]},{"id":"evidence-real-world-use","name":"Real-world use","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these real-world use hold for the sense of HTTP this model covers, and on what evidence?","id":"evidence-real-world-use-q01","kind":"provenance"}]},{"id":"evidence-measurements","name":"Typical measurements","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these typical measurements hold for the sense of HTTP this model covers, and on what evidence?","id":"evidence-measurements-q01","kind":"provenance"}]},{"id":"evidence-failure-modes-and-hazards","name":"Failure modes and hazards","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these failure modes and hazards hold for the sense of HTTP this model covers, and on what evidence?","id":"evidence-failure-modes-and-hazards-q01","kind":"provenance"}]},{"id":"evidence-regional-variation","name":"Regional variation","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these regional variation hold for the sense of HTTP this model covers, and on what evidence?","id":"evidence-regional-variation-q01","kind":"provenance"}]},{"id":"evidence-neighbours","name":"Neighbouring kinds and how to tell them apart","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these neighbouring kinds and how to tell them apart hold for the sense of HTTP this model covers, and on what evidence?","id":"evidence-neighbours-q01","kind":"provenance"}]}]}]}]},"agentConduct":{"may":["Send HTTP requests to services it is authorized to use, respecting their terms and rate limits.","Explain HTTP methods, status codes and headers from the specifications."],"mustNot":["Send requests to probe, overload or exploit services it is not authorized to test.","Use plain HTTP to send passwords or personal data.","Ignore a site's robots rules, rate limits or terms when crawling.","Forge headers to impersonate another client or user."],"requiresHuman":["Running load tests or security scans against production services."]},"ethics":{"considerations":["HTTP carries much of people's online life, so security and privacy matter.","Automated traffic can overload small sites."],"affectedParties":["Users of web services","Site operators","Developers"]},"owners":{"steward":"Nobody owns the protocol; the IETF maintains its specifications.","roles":[],"masterSystems":[]},"relations":[{"target":"Q15836568","type":"parent","note":"registry parent class"}],"interaction":{"identity":{"applicability":"required","items":["Vercy registry: vr.tr.http","Wikidata: Q8777 (https://www.wikidata.org/wiki/Q8777)"]},"properties":{"applicability":"not-applicable","items":["Observed HTTP version: HTTP/1.0 | HTTP/1.1 | HTTP/2 | HTTP/3 | other | unknown; recorded per hop","Request method: Case-sensitive method token with known, extension or unknown semantics","Target resource: Target URI, its scheme and authority, and its relationship to the contacted peer","Response status: Observed three-digit status code, informational or final role, and known or unknown meaning","Exchange completion: Not sent | in progress | informational response received | final response incomplete | complete | failed | outcome unknown","Representation description: Declared media type, content coding, language and presence or absence of relevant metadata","Cache reuse eligibility: Not evaluated | reusable while fresh | validation required | stale reuse permitted under recorded conditions | reuse prohibited","Freshness lifetime and current age: Seconds, with calculation inputs and observation time","Retry justification: Not assessed | justified by method and failure evidence | justified by an application guarantee | unjustified | uncertain"]},"recognition":{"applicability":"not-applicable","items":[]},"capabilities":{"applicability":"required","items":["Interpret a request and its response sequence using the applicable HTTP semantics.","Construct a request with suitable method, target, negotiation fields and preconditions.","Assess whether a failed or interrupted request may be retried and record the justification.","Decide whether a stored response may be reused, validated or replaced.","Evaluate a redirect or authentication challenge before choosing a follow-up request.","Diagnose protocol inconsistencies across message framing, intermediaries and version boundaries."]},"hazards":{"applicability":"required","items":["Unencrypted HTTP traffic can expose credentials, personal information and transferred content to interception or modification.","Automatic retries of operations without suitable safeguards can duplicate purchases, submissions or other state changes.","Incorrect caching can disclose private responses or deliver outdated information.","Inconsistent message interpretation between intermediaries and servers can undermine access controls and request routing."]},"interfaces":{"applicability":"required","items":["HTTP Semantics, RFC 9110, Internet Engineering Task Force (IETF)."]},"context":{"applicability":"required","items":["HTTP carries requests and responses between web clients, servers and intermediaries.","It is used to retrieve documents and media, exchange application data and invoke operations through web interfaces."]}},"sources":[{"title":"RFC 9110: HTTP Semantics","url":"https://www.rfc-editor.org/rfc/rfc9110","note":"Normative definition of HTTP as a protocol family, methods, status codes, fields, and resource/representation model"},{"title":"RFC 9112: HTTP/1.1","url":"https://www.rfc-editor.org/rfc/rfc9112","note":"HTTP/1.1 message syntax, persistent connections, and chunked transfer coding"},{"title":"RFC 9113: HTTP/2","url":"https://www.rfc-editor.org/rfc/rfc9113","note":"HTTP/2 binary framing, streams, and HPACK; ALPN token h2"},{"title":"RFC 9114: HTTP/3","url":"https://www.rfc-editor.org/rfc/rfc9114","note":"HTTP/3 mapping onto QUIC; distinction from the QUIC transport itself"},{"title":"RFC 2818: HTTP Over TLS","url":"https://www.rfc-editor.org/rfc/rfc2818","note":"HTTPS as HTTP over TLS, https URI scheme, and default port 443"},{"title":"Fetch Standard","url":"https://fetch.spec.whatwg.org/","note":"Browser-facing HTTP client behaviour, CORS, and redirects as implemented on the Web"},{"title":"Hypertext Transfer Protocol (Q8777)","url":"https://www.wikidata.org/wiki/Q8777","note":"Stable public identifier for the protocol as a catalogue item"},{"title":"Wikipedia: HTTP","url":"https://en.wikipedia.org/wiki/HTTP","note":"general description of the item"}],"openQuestions":["With no registry definition recorded, should this entry cover only the HTTP protocol family or also provide reusable records for individual exchanges and endpoint capabilities?","Which specification baseline and extension set should be adopted, including treatment of legacy HTTP/1.0, registered extension methods and evolving field definitions?","Where should the catalogue place cookie handling and browser-enforced policies so that this model can reference their effects without duplicating ownership?","What evidence will normally be available across intermediaries, and how should the model express conclusions that are valid only for one observed hop?","Which neighbouring model owns application-level idempotency keys and asynchronous operation completion, and what evidence must HTTP retry decisions obtain from it?"],"resources":{"spec":"/models/things/publications/thing-q8777/spec.json"},"provenance":{"origin":"thing registry research (pass 2)","builtFrom":["models/things/publications/thing-q8777/spec.json"],"providers":["Codex","Grok"],"researchStatus":"unreviewed","generatedAt":"2026-09-07T11:43:06Z","builder":"tools/build_cards.py@1.0.0"},"completeness":{"sections":{"classifiers":"filled","whatItIs":"filled","purpose":"filled","distinguishingFeatures":"filled","structure":"filled","agentConduct":"filled","ethics":"filled","owners":"filled","relations":"filled","interaction.identity":"filled","interaction.properties":"not-applicable","interaction.recognition":"not-applicable","interaction.capabilities":"filled","interaction.hazards":"filled","interaction.interfaces":"filled","interaction.context":"filled","sources":"filled"},"notes":{"_gate":"Published through the thing publication gate 1.0 on 2026-10-07T12:16:35+00:00: completeness 1.00; sense: Wikidata description; 4 live sources; review by codex: pass","interaction.properties":"Plane INF: no invented physical properties.","interaction.recognition":"HTTP is an abstract communication protocol whose identity requires interpretation of messages or metadata rather than visual identification."},"score":1.0}}