Destroyed https: www.facebook.com profile.php?id=100004528329069 (markdown)

https:--www.facebook.com-profile.php?id=100004528329069.md

@@ -1,17 +0,0 @@
-*Article is a WIP*
-
-- Use `httpserver.Path` to compare base paths to know whether your handler should handle the request (for example: `httpserver.Path(r.URL.Path).Matches(myHandler.BasePath)`)
-- Don't touch the file system using a path from the request directly, because doing so is vulnerable to path traversal attacks. Instead:
-    - To open a file, use `http.Dir` (standard lib)
-    - For anything else, use `httpserver.SafePath` to get a sanitized path
-- Honor the [`HiddenFiles` field on the httpserver.SiteConfig struct](https://godoc.org/github.com/mholt/caddy/caddyhttp/httpserver#SiteConfig) if your middleware accesses files on disk.
-- If you need to wrap or record the response, wrap your own `ResponseWriter` type with `httpserver.ResponseWriterWrapper` so it is guaranteed to implement some crucial interfaces.
-- The `http.Request.URL` (especially its `.Path` value) may be changed by other "rewriting" middlewares. You can always access the original incoming URL via context: `req.Context().Value(httpserver.OriginalURLCtxKey).(url.URL)`
-- Directives (and subdirectives) follow `underscore_convention` for naming. Lower-cased, with underscore as word separators. There may be rare exceptions to this (e.g. the `header` directive uses header field names, like `Content-Type` as subdirectives), but usually try to follow this convention. It will make the user's experience with your middleware consistent with the rest of Caddy. Avoid `camelCase` or `hyphen-separation`.
-- The first argument to a directive, where applicable, is often the base path to match on a request.
-- Use [httpserver.IndexFile()](https://godoc.org/github.com/mholt/caddy/caddyhttp/httpserver#IndexFile) in conjunction with [staticfiles.IndexPages](https://godoc.org/github.com/mholt/caddy/caddyhttp/staticfiles#pkg-variables) to determine whether a file is an index file.
-
-**For plugin authors in general (TODO: move to separate article when we get enough content):**
-
-- Plugins _may_ vendor their dependencies _as long as_ they do not export vendored types (i.e. they do not share vendored types with Caddy or with any other plugin). See https://github.com/mattfarina/golang-broken-vendor for why this is bad. (NOTE/TODO: Until Go 1.9 is released, plugins should only vendor deps that pass the Caddy build checks, such as `test -race` and `vet`. Because Go 1.8- tooling does not ignore the vendor/ directory...)
-- Do NOT vendor `github.com/mholt/caddy` OR any of the packages in that repository OR any packages your plugin "registers" with if they also plug into Caddy. Doing so will cause your plugin to register with the vendored copy instead of the "main" package where the compilation originates.