Publish specifications to specs.ipfs.tech

.config.json

@@ -0,0 +1,6 @@
+{
+  "input": "src",
+  "output": "out",
+  "template": "template.html",
+  "baseURL": "https://specs.ipfs.tech"
+}

.gitignore

@@ -0,0 +1 @@
+out/

.markdownlint.json

@@ -1,8 +1,11 @@
 {
   "single-h1": false,
+  "ul-style": false,
   "no-bare-urls": false,
+  "no-duplicate-heading": false,
   "no-emphasis-as-header": false,
   "fenced-code-language": false,
   "blanks-around-lists": false,
+  "single-trailing-newline": false,
   "line-length": false
 }

Makefile

@@ -1,4 +1,18 @@
-all: superlinter
+SPEC_GENERATOR_VER=v1.1.4
+
+all: website
+
+clean:
+	rm -rf ./out
+
+install:
+	npm install -g spec-generator@$(SPEC_GENERATOR_VER)
+
+website: clean install
+	spec-generator -c .config.json
+
+watch: clean install
+	spec-generator -c .config.json -w
 
 superlinter:
 	docker run --rm -e VALIDATE_ALL_CODEBASE=false -e RUN_LOCAL=true -e VALIDATE_MARKDOWN=true -e MARKDOWN_CONFIG_FILE=".markdownlint.json" -e LINTER_RULES_PATH="." -v $(shell pwd):/tmp/lint github/super-linter:v4

http-gateways/DNSLINK_GATEWAY.md

@@ -1,106 +1,3 @@
 # DNSLink Gateway Specification
 
-![reliable](https://img.shields.io/badge/status-reliable-green.svg?style=flat-square)
-
-**Authors**:
-
-- Marcin Rataj ([@lidel](https://github.com/lidel))
-
-----
-
-**Abstract**
-
-DNSLink Gateway is an extension of
-[PATH_GATEWAY.md](./PATH_GATEWAY.md)
-that enables hosting a specific content path under a specific DNS name.
-
-This document describes the delta between [PATH_GATEWAY.md](./PATH_GATEWAY.md) and this gateway type.
-
-In short:
-
-- HTTP request includes a valid [DNSLink](https://dnslink.dev/) name in `Host` header
-- gateway decides if DNSlink name is allowed
-- gateway resolves DNSLink to an immutable content root identified by a CID
-- HTTP response includes the data for the CID
-
-# Table of Contents
-
-- [DNSLink Gateway Specification](#dnslink-gateway-specification)
-- [Table of Contents](#table-of-contents)
-- [HTTP API](#http-api)
-  - [`GET /[{path}][?{params}]`](#get-pathparams)
-  - [`HEAD /[{path}][?{params}]`](#head-pathparams)
-- [HTTP Request](#http-request)
-  - [Request headers](#request-headers)
-    - [`Host` (request header)](#host-request-header)
-- [HTTP Response](#http-response)
-- [Appendix: notes for implementers](#appendix-notes-for-implementers)
-  - [Leveraging DNS for content routing](#leveraging-dns-for-content-routing)
-  - [Redirects, single-page applications, and custom 404s](#redirects-single-page-applications-and-custom-404s)
-
-# HTTP API
-
-## `GET /[{path}][?{params}]`
-
-Downloads data at specified path under the content path for DNSLink name provided in `Host` header.
-
-- `path` – optional path to a file or a directory under the content root sent in `Host` HTTP header
-  - Example: if `Host: example.com` then the content path to resolve is `/ipns/example.com/{path}`
-
-## `HEAD /[{path}][?{params}]`
-
-Same as GET, but does not return any payload.
-
-# HTTP Request
-
-Below MUST be implemented **in addition** to the [HTTP Request section from `PATH_GATEWAY.md`](./PATH_GATEWAY.md#http-request).
-
-## Request headers
-
-### `Host` (request header)
-
-Defines the [DNSLink](https://docs.ipfs.io/concepts/glossary/#dnslink) name
-to RECURSIVELY resolve into an immutable `/ipfs/{cid}/` prefix that should
-be prepended to the `path` before the final IPFS content path resolution
-is performed.
-
-Implementations MUST ensure DNSLink resolution is safe and correct:
-
-- each DNSLink may include an additional path segment, which MUST be preserved
-- each DNSLink may point at other DNSLink, which means there MUST be a hard
-  recursion limit (e.g. 32) and HTTP 400 Bad Request error MUST be returned
-  when the limit is reached.
-
-**Example: resolving an advanced DNSLink chain**
-
-To illustrate, given DNSLink records:
-
-- `_dnslink.a.example.com` TXT record: `dnslink=/ipns/b.example.net/path-b`
-- `_dnslink.b.example.net` TXT record: `dnslink=/ipfs/bafy…qy3k/path-c`
-
-HTTP client sends `GET /path-a` request with  `Host: a.example.com` header
-which recursively resolves all DNSLinks and produces the final immutable
-content path:
-
-1. `Host` header + `/path-a` → `/ipns/a.example.net/path-a`
-2. Resolving DNSlink at `a.example.net` replaces `/ipns/a.example.net` with `/ipns/b.example.net/path-b`
-3. Resolving DNSlink at `b.example.net` replaces `/ipns/b.example.net` with `/ipfs/bafy…qy3k/path-c`
-4. The immutable content path is `/ipfs/bafy…qy3k/path-c/path-b/path-a`
-
-# HTTP Response
-
-Same as [HTTP Response section in `PATH_GATEWAY.md`](./PATH_GATEWAY.md#http-response).
-
-# Appendix: notes for implementers
-
-## Leveraging DNS for content routing
-
-- It is a good idea to publish
-  [DNSAddr](https://github.com/multiformats/multiaddr/blob/master/protocols/DNSADDR.md)
-  TXT records with known content providers for the data behind a DNSLink. IPFS
-  clients will be able to detect DNSAddr and preconnect to known content
-  providers, removing the need for expensive DHT lookup.
-
-## Redirects, single-page applications, and custom 404s
-
-DNSLink Gateway implementations are free to include `_redirects` file support defined in [`REDIRECTS_FILE.md`](./REDIRECTS_FILE.md).
+Moved to https://specs.ipfs.tech/http-gateways/dnslink-gateway/