Sign inRegisterCheck connection

Publishing ClientRaw Files at /weather/raw

Publishing Weather Display ClientRaw files at a public /weather/raw path as a data contract: access control, stale packets, and directory layout.

Back to Historical weather observations and forecasts

A well-known directory of Weather Display ClientRaw files is a data contract, not a web form. Other sites, AJAX templates, and research notes historically fetched clientraw.txt and its siblings from a stable public path. On the historical TNET Weather site that path was /weather/raw (and nearby /weather directories). The contract is: these filenames exist here, they are overwritten on a stated cadence, they are world-readable or they are not, and a consumer may treat a successful GET as the station’s current packet—not as a promise that the packet is fresh.

The Wayback snapshot at this URL showed a ClientRaw parser form. That diagnostic belongs at /wd-parser.php. This article does not rebuild the form, does not fetch other people’s URLs, and does not clone the parser essay. It is about publishing the files: layout, access control, staleness, and what a remote consumer is allowed to assume.

Historical context

Weather Display’s real-time FTP feature uploads a family of compact text files so a website can show current conditions without regenerating HTML on every sample. The usual names are clientraw.txt, clientrawextra.txt, clientrawdaily.txt, and clientrawhour.txt. Templates and Weather Display Live were written to look in one directory. Operators therefore published that directory at a short, memorable path. Other PWS sites, and at least one university weather-feed note, treated such a path as a feed.

A parser is a reader. A raw directory is a publisher. Mixing them on one URL taught visitors to paste arbitrary addresses into a form that then pulled files server-side. The diagnostic risks of that form—timeouts, server-side request forgery, treating someone else’s feed as your own—are covered on the parser page. /weather/raw should have been, and is now described as, the station’s publication point.

The files themselves are Weather Display’s format, originated by Brian Hamilton. The authoritative field map is clientrawdescription.txt on the PC that wrote the packet. See the ClientRaw family reference for grain and versioning. This page does not reprint a field list.

The directory is the API

A public ClientRaw publication has a small, strict surface:

| Object | Role | |---|---| | Directory URL | Stable base (/weather/raw/ with a trailing-slash policy you document) | | Four filenames | Live, extra, daily, hour — or documented custom names | | HTTP 200 + body | The packet, not an HTML wrapper, not a login page | | Content type | text/plain (or another documented type). HTML error pages must not look like packets | | Cadence | How often FTP or copy replaces each file | | Clock | Packet time fields plus HTTP Last-Modified if the server sets it |

Consumers index by position, not by column name. If you prepend a comment line, wrap the file in HTML, or serve a directory listing as index.html in place of clientraw.txt, every downstream widget breaks. The contract is a single line (or a documented line count) of space-separated fields, often ending in a version token.

Custom names are allowed only if you publish a machine-readable note next to them. Silent renaming is a broken contract.

Do not put the live packet behind a PHP script that reprints it as a table and still call the URL /weather/raw. The raw path should return the file bytes Weather Display wrote, or an honest HTTP error.

Access control is part of the contract

“Public path” does not have to mean “no thought.” It means the access rule is explicit.

Open read, no listing. Many operators allowed GET of the four filenames and disabled directory indexes so crawlers did not harvest leftover dumps. That is a coherent policy: the packets are the product; the folder inventory is not.

Open read, with listing. Convenient for humans, noisy for bots, easy to leak old test files named clientraw.bak. If you list, prune.

Authenticated read. Reasonable when the station is not meant to be a public feed. Then /weather/raw is the wrong mnemonic for third-party templates. Do not advertise a public ClientRaw path and then 401 the files. Pick one.

Hotlink and scrape cost. These files are tiny compared with PNG graph scripts, but they are requested at dashboard cadence. A stable URL will be polled. Rate-limiting or caching headers (Cache-Control, ETag, Last-Modified) are part of being a feed. An unbounded PHP wrapper around the file is not.

Do not use the publication host as a proxy. If your “raw” page accepts ?url= and fetches another station, you have rebuilt the parser’s SSRF problem at the data path. Publication is your files.

Robots policy and Referer checks do not replace the above. They also do not make a stale file fresh.

Stale files are a publishing failure

ClientRaw is a current-state packet. Its scientific value is freshness. A file that is present and parseable but hours old is a failed upload, a stopped logger, or a clock stuck on the PC—not “calm weather.”

Checks a publisher owes consumers:

  1. Packet time versus wall time. The live file carries fragmented date/time fields. If they stop advancing, the feed is dead. HTTP Last-Modified should agree within the upload cadence; if the web server never updates mtime because of a copy trick, say so.
  2. Independent ages per file. It is common for clientraw.txt to update while clientrawhour.txt is stuck. A consumer that only GETs the live file will not see that. Publishers should monitor all four.
  3. Atomic replace. FTP into the live name can expose a truncated line. Write to a temp name, then rename. A truncated packet shifts every field; remote widgets will display humidity as wind without throwing.
  4. Sentinels and placeholders. Unused extra sensors still occupy slots. Zero may mean zero or missing. Document which. Do not rely on consumers to guess.
  5. HTTPS and mixed content. A template on HTTPS that still points at http://…/weather/raw will fail in browsers even when the file is fine. The contract includes the scheme you support.

A parser UI that prints named fields is how an operator debugs those failures. It is not how the directory should behave. Point operators to /wd-parser.php and to a maintained decoder such as Saratoga’s WD parser (last checked 13 August 2026) if they need an interactive dump. Keep /weather/raw boring: files or HTTP errors.

What consumers may assume—and must not

They may assume: filename, format family, and that a 200 with a leading label and a trailing version token is a WD packet from this host.

They must not assume: WMO siting, NWS quality control, correct units at the display edge, or that extra/daily/hour files are as fresh as the live file. Native ClientRaw units are typically SI-leaning (Celsius, millimetres, knots, hectopascals) even when the website shows Fahrenheit and inches. Conversion is the consumer’s problem unless you publish a sidecar that states display units. The family reference is the place for that encoding discussion.

They must not assume the path is a climate archive. Overwrite-in-place destroys history unless you copy packets elsewhere on a schedule. /weather/raw is not a year of rain. It is now, plus whatever short rings the extra and hour files still hold.

Practical checklist for operators

  • Four files (or documented names) at one base URL; no HTML wrapper.
  • Directory index policy chosen and leftover backups removed.
  • Upload is atomic; cadence is documented.
  • Each file’s age is monitored, not only the live packet.
  • Access is either public GET or authenticated—not a surprise 401 on a advertised feed.
  • No ?url= proxy on this path.
  • Field map version lives with the WD build, not as folklore on the website.
  • This path is not a parser form.

Modern relevance

Compact, frequently overwritten observation files are still how station software talks to the web. Whether the name is ClientRaw, Cumulus realtime.txt, or a vendor JSON loop, the publication questions are the same: stable URL, explicit access, freshness, and a schema that does not silently move. TNET’s public discussion of source quality and provenance is data sources, quality controls, and methodology. The Weather Display hub and the observations hub sit beside this contract.

This URL does not host live ClientRaw bytes as a restored feed, and it does not offer a paste-a-URL decoder. It states what a public /weather/raw path was for: a dataset other sites could fetch without scraping HTML.

Sources