chore: lint http-gateways

ipfs · Sep 2, 2022 · afda5f5 · afda5f5
1 parent d5d7253
commit afda5f5
Show file tree

Hide file tree

Showing 3 changed files with 40 additions and 40 deletions.
diff --git a/http-gateways/DNSLINK_GATEWAY.md b/http-gateways/DNSLINK_GATEWAY.md
@@ -23,7 +23,7 @@ In short:
 - gateway resolves DNSLink to an immutable content root identified by a CID
 - HTTP response includes the data for the CID
 
-# Table of Contents
+## Table of Contents
 
 - [DNSLink Gateway Specification](#dnslink-gateway-specification)
 - [Table of Contents](#table-of-contents)
@@ -37,9 +37,9 @@ In short:
 - [Appendix: notes for implementers](#appendix-notes-for-implementers)
   - [Leveraging DNS for content routing](#leveraging-dns-for-content-routing)
 
-# HTTP API
+## HTTP API
 
-## `GET /[{path}][?{params}]`
+### `GET /[{path}][?{params}]`
 
 Downloads data at specified path under the content path for DNSLink name provided in `Host` header.
 
@@ -50,13 +50,13 @@ Downloads data at specified path under the content path for DNSLink name provide
 
 Same as GET, but does not return any payload.
 
-# HTTP Request
+## HTTP Request
 
 Below MUST be implemented **in addition** to the [HTTP Request section from `PATH_GATEWAY.md`](./PATH_GATEWAY.md#http-request).
 
-## Request headers
+### Request headers
 
-### `Host` (request header)
+#### `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
@@ -85,13 +85,13 @@ content path:
 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
+## HTTP Response
 
 Same as [HTTP Response section in `PATH_GATEWAY.md`](./PATH_GATEWAY.md#http-response).
 
-# Appendix: notes for implementers
+## Appendix: notes for implementers
 
-## Leveraging DNS for content routing
+### Leveraging DNS for content routing
 
 - It is a good idea to publish
   [DNSAddr](https://github.com/multiformats/multiaddr/blob/master/protocols/DNSADDR.md)

diff --git a/http-gateways/SUBDOMAIN_GATEWAY.md b/http-gateways/SUBDOMAIN_GATEWAY.md
@@ -25,7 +25,7 @@ Summary:
 - Data is retrieved from IPFS in a way that is compatible with URL-based addressing
   - URL’s path `/` points at the content root identified by the CID
 
-# Table of Contents
+## Table of Contents
 
 - [Subdomain Gateway Specification](#subdomain-gateway-specification)
 - [Table of Contents](#table-of-contents)
@@ -50,30 +50,30 @@ Summary:
   - [Security considerations](#security-considerations)
   - [URI router](#uri-router)
 
-# HTTP API
+## HTTP API
 
 The API is a superset of [PATH_GATEWAY.md](./PATH_GATEWAY.md), the differences
 are documented below.
 
 The main one is that Subdomain Gateway expects CID to be present in the `Host` header.
 
-## `GET /[{path}][?{params}]`
+### `GET /[{path}][?{params}]`
 
 Downloads data at specified content path.
 
 - `path` – optional path to a file or a directory under the content root sent in `Host` HTTP header
 
-## `HEAD /[{path}][?{params}]`
+### `HEAD /[{path}][?{params}]`
 
 Same as GET, but does not return any payload.
 
-# HTTP Request
+## HTTP Request
 
 Below MUST be implemented **in addition** to the [HTTP Request section from `PATH_GATEWAY.md`](./PATH_GATEWAY.md#http-request).
 
-## Request Headers
+### Request Headers
 
-### `Host` (request header)
+#### `Host` (request header)
 
 Defines the root that should be prepended to the `path` before IPFS content
 path resolution is performed.
@@ -108,7 +108,7 @@ Converting `Host` into a content path depends on the nature of requested resourc
 - Finally, if it is impossible to construct a content path from `Host`,
   return HTTP Error [`400` Bad Request](./PATH_GATEWAY.md#400-bad-request).
 
-### `X-Forwarded-Proto` (request header)
+#### `X-Forwarded-Proto` (request header)
 
 Optional. Allows `http://` gateway implementation to be deployed behind
 reverse proxies that provide TLS (`https://`) termination.
@@ -125,7 +125,7 @@ Example (GET with `X-Forwarded-Proto: https`):
 - `GET http://dweb.link/ipfs/{cid}` → HTTP 301 with `Location: https://{cid}.ipfs.dweb.link`
 - `GET http://dweb.link/ipns/your-dnslink.site.example.com` → HTTP 301 with `Location: https://your--dnslink-site-example-com.ipfs.dweb.link`
 
-### `X-Forwarded-Host` (request header)
+#### `X-Forwarded-Host` (request header)
 
 Optional. Enables Path Gateway requests to be redirected to a Subdomain Gateway
 on a different domain name.
@@ -136,26 +136,26 @@ Example (GET with `X-Forwarded-Host: example.com`):
 
 - `GET https://dweb.link/ipfs/{cid}` → HTTP 301 with `Location: https://{cid}.ipfs.example.com`
 
-## Request Query Parameters
+### Request Query Parameters
 
-### `uri` (request query parameter)
+#### `uri` (request query parameter)
 
 Optional. When present, passed address should override regular path routing.
 
 See [URI router](#uri-router) section for usage and implementation details.
 
-# HTTP Response
+## HTTP Response
 
 Below MUST be implemented **in addition** to the [HTTP Response section from `PATH_GATEWAY.md`](./PATH_GATEWAY.md#http-response).
 
-## Response Headers
+### Response Headers
 
-### `Location` (response header)
+#### `Location` (response header)
 
 Below MUST be implemented **in addition** to
 [`Location` reqirements defined in `PATH_GATEWAY.md`](./PATH_GATEWAY.md#location-response-header).
 
-#### Use in interop with Path Gateway
+##### Use in interop with Path Gateway
 
 Returned with [`301` Moved Permanently](./PATH_GATEWAY.md#301-moved-permanently) when `Host` header does
 not follow the subdomain naming convention, but the requested URL path happens
@@ -175,13 +175,13 @@ form if necessary. For example:
 
 See also: [Migrate from Path to Subdomain Gateway](#migrating-from-path-to-subdomain-gateway).
 
-#### Use in URI router
+##### Use in URI router
 
 See: [URI router](#uri-router)
 
-# Appendix: notes for implementers
+## Appendix: notes for implementers
 
-## Migrating from Path to Subdomain Gateway
+### Migrating from Path to Subdomain Gateway
 
 Subdomain Gateway MUST implement a redirect on paths defined in [`PATH_GATEWAY.md`](./PATH_GATEWAY.md).
 
@@ -198,7 +198,7 @@ It is up to the gateway operator to clearly communicate when such a transition
 is to happen, or use a different domain name for subdomain gateway to avoid
 breaking legacy clients that are unable to follow HTTP 301 redirects.
 
-## DNS label limits
+### DNS label limits
 
 DNS labels, must be case-insensitive, and up to a maximum of 63 characters
 [per label](https://datatracker.ietf.org/doc/html/rfc2181#section-11).
@@ -217,7 +217,7 @@ characters, such as those for `sha2-512` hashes, remains an
 Until a solution is found, subdomain gateway implementations
 should return HTTP 400 Bad Request for CIDs longer than 63.
 
-## Security considerations
+### Security considerations
 
 - Wildcard TLS certificates should be set for `*.ipfs.example.net` and
   `*.ipns.example.net` if a subdomain gateway is to be exposed on the public
@@ -237,7 +237,7 @@ should return HTTP 400 Bad Request for CIDs longer than 63.
       pattern `https://{content-root-id}.ip[f|n]s.example.net`) and dynamically
       add it to PSL.
 
-## URI router
+### URI router
 
 Optional [`uri`](#uri-request-query-parameter) query parameter overrides regular path routing.
 

diff --git a/http-gateways/TRUSTLESS_GATEWAY.md b/http-gateways/TRUSTLESS_GATEWAY.md
@@ -20,7 +20,7 @@ The minimal implementation means:
 - no path traversal or recursive resolution, no UnixFS/IPLD decoding server-side
 - response type is always fully verifiable: client can decide between a raw block or a CAR stream
 
-# Table of Contents
+## Table of Contents
 
 - [Trustless Gateway Specification](#trustless-gateway-specification)
 - [Table of Contents](#table-of-contents)
@@ -34,25 +34,25 @@ The minimal implementation means:
   - [HTTP Response Headers](#http-response-headers)
     - [`Content-Disposition` (response header)](#content-disposition-response-header)
 
-# HTTP API
+## HTTP API
 
 A subset of [HTTP API from `PATH_GATEWAY.md`](./PATH_GATEWAY.md#http-api).
 
-## `GET /ipfs/{cid}[?{params}]`
+### `GET /ipfs/{cid}[?{params}]`
 
 Downloads data at specified CID.
 
-## `HEAD /ipfs/{cid}[?{params}]`
+### `HEAD /ipfs/{cid}[?{params}]`
 
 Same as GET, but does not return any payload.
 
-# HTTP Request
+## HTTP Request
 
 Same as in [PATH_GATEWAY.md](./PATH_GATEWAY.md#http-request), but with limited number of supported response types.
 
-## HTTP Request Headers
+### HTTP Request Headers
 
-### `Accept` (request header)
+#### `Accept` (request header)
 
 This HTTP header is required when running in a strict, trustless mode.
 
@@ -63,12 +63,12 @@ Below response types MUST to be supported:
 - [application/vnd.ipld.raw](https://www.iana.org/assignments/media-types/application/vnd.ipld.raw) – requests a single, verifiable raw block to be returned
 - [application/vnd.ipld.car](https://www.iana.org/assignments/media-types/application/vnd.ipld.car) – disables IPLD/IPFS deserialization, requests a verifiable CAR stream to be returned
 
-# HTTP Response
+## HTTP Response
 
 Below MUST be implemented **in addition** to the [HTTP Response section from `PATH_GATEWAY.md`](./PATH_GATEWAY.md#http-response).
 
-## HTTP Response Headers
+### HTTP Response Headers
 
-### `Content-Disposition` (response header)
+#### `Content-Disposition` (response header)
 
 MUST be returned and set to `attachment` to ensure requested bytes are not rendered by a web browser.