Essay 001

Who Speaks for the Server?

When a refusal reflects a publisher’s instruction, delegated control or a provider’s own decision.

In this essay

Abstract

I argue that a server’s refusal cannot be attributed to a publisher merely because the request concerned the publisher’s website, although the absence of an individual dashboard choice does not establish that the refusal lacked authority. By distinguishing a deliberate configuration, an authorised default and an independent infrastructure decision, I show why control of a computer resource and authority over a copyrighted work may require different evidence. My proposed inquiry follows the resource, the decision and the scope of delegation, using the limited aninews.in observation to explain why a status code alone cannot identify the person who spoke.

When I read a refused request, I can usually identify the response more easily than the decision behind it, because a server can return the same status code whether a publisher selected the restriction, delegated the choice or knew nothing about the particular event. That gap is the subject of this essay, which asks how I would connect a technical refusal to a person whose authority gives it legal significance.

My starting point is the limited finding in NOTE 001, where my RightSignal 1.1 request for the robots.txt file at aninews.in received Hypertext Transfer Protocol ("HTTP") 403 although I could retrieve the file manually. The retained research record does not identify the responsible rule or provider, so the examples below are analytical situations rather than claims about the infrastructure used by that website.

A setting can distinguish uses without refusing a request

The controls offered by an infrastructure provider can do more than admit or reject a crawler, as Cloudflare’s September 2026 description of its Disallow AI Training setting illustrates through its distinction between blocking mixed-use crawlers and preserving search access while signalling an objection to training. Its account also describes migration from earlier settings, which makes the history of the customer’s choices relevant when examining how a later configuration came into operation.

I draw a narrow lesson from that documentation, because the existence of such controls demonstrates that a training preference and an access refusal need not coincide, while saying nothing about which setting another website selected. A screenshot of a current dashboard would likewise leave me needing the earlier configuration and the relevant service terms before I could attribute a historical response.

This matters particularly for content delivery networks ("CDNs"), which can answer a request at their own edge infrastructure before it reaches a publisher’s origin server, because operational control and the ownership of the content may sit with different people. I therefore begin with the resource and the relevant act, rather than treating the domain name as a complete account of who controlled the encounter.

In motion · scroll or step through

One refusal, three possible speakers

The same status code can leave the edge of a network whether the publisher chose the rule, entrusted the choice to a provider or knew nothing about it. Follow the request and the decision behind it separately.

  1. Step 1 of 7 · One refusal

    A crawler asks for an article and receives 403

    A research crawler requests an article and receives HTTP 403. The response looks identical in every situation that follows, which is exactly why the status code alone cannot identify the person whose decision it expresses.

  2. Step 2 of 7 · Two machines

    The edge can answer before the origin is reached

    Many websites sit behind a content delivery network ("CDN"), whose edge servers can answer a request before it ever reaches the publisher’s own origin server. Operational control of the edge and ownership of the work on the origin may therefore sit with different people.

  3. Step 3 of 7 · Chosen

    Situation one · the publisher chose the rule

    Suppose the publisher instructs its provider to block a named crawler from a set of paths, and a retained configuration shows the rule active when the request arrived. The instruction, the deployment record and the matched response then support one another, because they connect a decision to its implementation.

    Even here, a rule chosen to limit excessive requests may restrict access without saying anything about later training, so the evidence reaches only as far as the act, resource and purpose it covers.

  4. Step 4 of 7 · Delegated

    Situation two · the publisher entrusted the choice

    Suppose instead that the publisher accepted a managed service that sets and updates restrictions within an agreed scope. Sections 186 to 188 of the Indian Contract Act, 1872 direct attention to what was entrusted, and the difficult question is whether authority to protect availability also covers communicating a copyright reservation.

  5. Step 5 of 7 · Provider

    Situation three · the provider acted for itself

    Suppose finally that the infrastructure operator refused the request to protect its own network, independently of anything the publisher wanted. The response may still matter to access, but it gives a weak foundation for attributing a copyright prohibition to a publisher who took no part in the decision.

  6. Step 6 of 7 · Two authorities

    Access law and copyright ask about different people

    Section 43 of the Information Technology Act, 2000 ("IT Act") asks about the owner or person in charge of the computer resource, while section 52(1)(c) of the Copyright Act, 1957 refers to an express prohibition by the right holder. Authority over a server does not necessarily include authority over every work it serves.

  7. Step 7 of 7 · Two records

    Each side preserves what it is placed to know

    The publisher can connect the instruction to the agreement authorising it, the resources affected and the period it operated, while the collector can keep the request, the complete response and its client configuration. Attribution then becomes a connection demonstrated between a person, an entrusted decision and the response, rather than an assumption drawn from a domain name.

The publisher deliberately chose the restriction

In the first situation, suppose a publisher instructs its provider to block a named crawler from a specified set of paths, and a retained configuration shows that the rule was active when the request arrived. I regard the instruction, deployment record and matched response as mutually supporting evidence, because they connect a decision to an implementation rather than merely placing a refusal beside the publisher’s name.

Even that relatively clear example requires attention to scope, since a rule selected to prevent excessive requests might establish a restriction on access without communicating any view about subsequent training. The fact that I can identify the publisher as the decision-maker does not entitle me to expand the decision beyond the act, resource or purpose the evidence supports.

Under section 43 of the Information Technology Act, 2000 ("IT Act"), the relevant permission concerns the owner or person in charge of the computer resource, whereas section 52(1)(c) of the Copyright Act, 1957 refers to an express prohibition by the right holder. I keep those inquiries separate even where one configuration supplies evidence relevant to both, because authority over a server does not necessarily include authority over every work it serves.

The publisher authorised the provider to choose

The second situation is more difficult because the publisher has accepted a managed service that makes or updates restrictions within an agreed scope, without selecting each resulting rule individually. I do not infer the absence of authority from the absence of a fresh click, since a service agreement may already authorise the provider to choose how to carry out the entrusted task.

Sections 186 to 188 of the Indian Contract Act, 1872 distinguish express and implied authority and address its extent, which directs attention to what was entrusted rather than to whether a setting is called a default. In my view, the difficult question is whether authority to protect availability or prevent abuse also encompasses communicating a purpose-specific copyright reservation, because those decisions can affect different interests and need not be included in the same delegation.

Suppose a publisher authorises its provider to manage malicious traffic but separately invites a research crawler to collect specified pages, and the provider’s general rule nevertheless refuses that crawler. The terms allocating control deserve attention first, alongside the scope of the permission and any exception process, because the apparent contradiction may concern the management of different resources or an implementation failure rather than a simple withdrawal of consent.

Later approval may introduce a question of ratification under sections 196 to 200 of the Contract Act, but I cannot backdate the publisher’s knowledge or assume that subsequent adoption resolves the position of an earlier recipient. The statutory requirements concerning material knowledge and the protection of third persons remain relevant, so the record should preserve when the publisher acted and what it knew rather than rewriting the history to match its later position.

The provider acted for its own purposes

In the third situation, suppose an infrastructure operator refuses a request to protect its own network, independently of a publisher’s preference about the work. The response may still matter to the access inquiry, because the operator may own or be in charge of the resource concerned, although that status and the boundaries of the relevant resource require evidence rather than an assumption based on a response header.

The same event would provide a weaker foundation for attributing a copyright prohibition to the publisher unless the operator held the necessary authority, which is why I reject a rule that turns every security response into a reservation of every downstream use. Such a rule would make the content owner’s legal position depend on operational decisions that may neither concern the work nor distinguish the purpose for which it is sought.

The objection is that a crawler cannot investigate private service agreements before every request, and I agree that a workable practice cannot require that investigation as an ordinary condition of browsing. My proposal instead separates the collector’s immediate treatment of a refusal from the evidence needed to make a later legal claim about it, allowing the response to be retained and respected without pretending that its author or legal scope has already been conclusively identified.

The record I would ask each side to preserve

For the publisher, I would connect the version of the instruction to the agreement or decision authorising it, the affected resources and the period during which it operated, while asking the provider’s records to explain which rule matched the request. For the collector, I would retain the request and complete response together with its client configuration, because that establishes the encounter whose attribution is disputed without claiming access to the publisher’s internal decision-making.

This allocation follows the information each participant is placed to retain, rather than announcing a judicial burden of proof that the statutes themselves have not supplied for every situation. It also permits an account to remain incomplete where one participant’s records are unavailable, which is preferable to filling the gap by treating either a permissive response or an unexplained block as the publisher’s fully informed choice.

I therefore understand attribution as a connection that must be demonstrated between a person, an entrusted decision and the response under examination, with the legal relevance of that connection assessed for the particular right involved. ESSAY 002 examines the proposed copyright route for retrieval copies, while NOTE 002 explains how the underlying observations can be preserved without allowing a later account of authority to overwrite the earlier record.

Cite this essay

OSCOLA

Manraj Singh Chandpuri, ‘Who Speaks for the Server?’ (LEX.TXT, 24 September 2026) <https://manrajchandpuri.com/lex/essays/who-speaks-for-the-server>.

Bluebook

Manraj Singh Chandpuri, Who Speaks for the Server?, LEX.TXT (Sept. 24, 2026), https://manrajchandpuri.com/lex/essays/who-speaks-for-the-server.

APA

Chandpuri, M. S. (2026, September 24). Who speaks for the server?. LEX.TXT. https://manrajchandpuri.com/lex/essays/who-speaks-for-the-server

Plain text

Manraj Singh Chandpuri, “Who Speaks for the Server?,” LEX.TXT, Essay 001, 24 September 2026, https://manrajchandpuri.com/lex/essays/who-speaks-for-the-server.

BibTeX

@online{chandpuri2026speaks, author = {Chandpuri, Manraj Singh}, title = {Who Speaks for the Server?}, subtitle = {When a refusal reflects a publisher’s instruction, delegated control or a provider’s own decision.}, organization = {LEX.TXT}, date = {2026-09-24}, url = {https://manrajchandpuri.com/lex/essays/who-speaks-for-the-server}, note = {Essay 001} }

Record

Identifier
LEX.TXT/ESSAY/001
Permalink
https://manrajchandpuri.com/lex/essays/who-speaks-for-the-server
Published
2026-09-24
Last modified
2026-09-25
Policy at publication
Version 0.3
Current permission
Applicable rights · Inspect this page’s signals
Reading copy
Read as Markdown
Source digest
sha256:e00fbd45809573400e26d3d9e7b1fb20ef3ecb7959247da0a5354e2013fdb014

Continue reading