From a4f0cb94b77ea643fe9790af9f9f56485d713c20 Mon Sep 17 00:00:00 2001 From: Pascal Dennerly Date: Sun, 12 Jan 2020 14:39:17 +0000 Subject: [PATCH 1/7] Update to make reference struct generic --- cmd/root.go | 8 +-- httpref.go | 150 ++++++++++++++++++++++++------------------------ httpref_test.go | 6 +- 3 files changed, 82 insertions(+), 82 deletions(-) diff --git a/cmd/root.go b/cmd/root.go index 49f6399..31fb972 100644 --- a/cmd/root.go +++ b/cmd/root.go @@ -41,19 +41,19 @@ func root(cmd *cobra.Command, args []string) error { fmt.Fprintf(os.Stderr, "Must specify a status code, or part of it\n") os.Exit(1) } else { - results = results.ByCode(args[0]) + results = results.ByName(args[0]) } } switch len(results) { case 0: - fmt.Fprintf(os.Stderr, "Code note recognised\n") + fmt.Fprintf(os.Stderr, "Name note recognised\n") os.Exit(1) case 1: - fmt.Printf("%s - %s\n\n%s\n", results[0].Code, results[0].Summary, results[0].Description) + fmt.Printf("%s - %s\n\n%s\n", results[0].Name, results[0].Summary, results[0].Description) default: for _, r := range results { - fmt.Printf("\t%s\t%s\n", r.Code, r.Summary) + fmt.Printf("\t%s\t%s\n", r.Name, r.Summary) } } diff --git a/httpref.go b/httpref.go index 115444a..54c53bd 100644 --- a/httpref.go +++ b/httpref.go @@ -2,19 +2,19 @@ package httpref import "strings" -type StatusRef struct { - Code string +type Reference struct { + Name string Summary string Description string } -type StatusRefs []StatusRef +type References []Reference -func (r StatusRefs) ByCode(code string) StatusRefs { - results := StatusRefs{} +func (r References) ByName(code string) References { + results := References{} for _, v := range r { - if strings.HasPrefix(v.Code, code) { + if strings.HasPrefix(v.Name, code) { results = append(results, v) } } @@ -22,15 +22,15 @@ func (r StatusRefs) ByCode(code string) StatusRefs { return results } -var Statuses = StatusRefs{ +var Statuses = References{ { - Code: "1xx", + Name: "1xx", Summary: "Informational response", Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Status https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#1xx_Informational_response`, }, { - Code: "100", + Name: "100", Summary: "Continue", Description: `The HTTP 100 Continue informational status response code indicates that everything so far is OK and that the client should continue with the request or ignore it if it is already finished. @@ -39,7 +39,7 @@ To have a server check the request's headers, a client must send Expect: 100-con https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100`, }, { - Code: "101", + Name: "101", Summary: "Switching Protocols", Description: `The HTTP 101 Switching Protocols response code indicates the protocol the server is switching to as requested by a client which sent the message including the Upgrade request header. @@ -48,25 +48,25 @@ The server includes in this response an Upgrade response header to indicate the https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/101`, }, { - Code: "102", + Name: "102", Summary: "Processing (WebDAV)", Description: `This code indicates that the server has received and is processing the request, but no response is available yet.`, }, { - Code: "103", + Name: "103", Summary: "Early Hints", Description: `The HTTP 103 Early Hints information response status code is primarily intended to be used with the Link header to allow the user agent to start preloading resources while the server is still preparing a response. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103`, }, { - Code: "2xx", + Name: "2xx", Summary: "Successful responses", Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Status https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#2xx_Success`, }, { - Code: "200", + Name: "200", Summary: "OK", Description: `The HTTP 200 OK success status response code indicates that the request has succeeded. A 200 response is cacheable by default. @@ -82,7 +82,7 @@ The successful result of a PUT or a DELETE is often not a 200 OK but a 204 No Co https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200`, }, { - Code: "201", + Name: "201", Summary: "Created", Description: `The HTTP 201 Created success status response code indicates that the request has succeeded and has led to the creation of a resource. The new resource is effectively created before this response is sent back and the new resource is returned in the body of the message, its location being either the URL of the request, or the content of the Location header. @@ -91,14 +91,14 @@ The common use case of this status code is as the result of a POST request. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201`, }, { - Code: "202", + Name: "202", Summary: "Accepted", Description: `The HyperText Transfer Protocol (HTTP) 202 Accepted response status code indicates that the request has been received but not yet acted upon. It is non-committal, meaning that there is no way for the HTTP to later send an asynchronous response indicating the outcome of processing the request. It is intended for cases where another process or server handles the request, or for batch processing. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202`, }, { - Code: "203", + Name: "203", Summary: "Non-Authoritative Information ", Description: `The HTTP 203 Non-Authoritative Information response status indicates that the request was successful but the enclosed payload has been modified by a transforming proxy from that of the origin server's 200 (OK) response . @@ -107,7 +107,7 @@ The 203 response is similar to the value 214, meaning Transformation Applied, of https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/203`, }, { - Code: "204", + Name: "204", Summary: "No Content", Description: `The HTTP 204 No Content success status response code indicates that the request has succeeded, but that the client doesn't need to go away from its current page. A 204 response is cacheable by default. An ETag header is included in such a response. @@ -116,14 +116,14 @@ The common use case is to return 204 as a result of a PUT request, updating a re https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204`, }, { - Code: "205", + Name: "205", Summary: "Reset Content", Description: `The HTTP 205 Reset Content response status tells the client to reset the document view, so for example to clear the content of a form, reset a canvas state, or to refresh the UI. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/205`, }, { - Code: "206", + Name: "206", Summary: "Partial Content (WebDAV)", Description: `The HTTP 206 Partial Content success status response code indicates that the request has succeeded and has the body contains the requested ranges of data, as described in the Range header of the request. @@ -134,34 +134,34 @@ If several ranges are sent back, the Content-Type is set to multipart/byteranges https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206`, }, { - Code: "207", + Name: "207", Summary: "Multi-Status (WebDAV)", Description: `Conveys information about multiple resources, for situations where multiple status codes might be appropriate. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status`, }, { - Code: "208", + Name: "208", Summary: "Already Reported (WebDAV)", Description: `Used inside a response element to avoid repeatedly enumerating the internal members of multiple bindings to the same collection. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status`, }, { - Code: "226", + Name: "226", Summary: "IM Used", Description: `The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status`, }, { - Code: "3xx", + Name: "3xx", Summary: "Redirection messages", Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Status https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection`, }, { - Code: "300", + Name: "300", Summary: "Multiple Choices", Description: `The HTTP 300 Multiple Choices redirect status response code indicates that the request has more than one possible responses. The user-agent or the user should choose one of them. As there is no standardized way of choosing one of the responses, this response code is very rarely used. @@ -170,7 +170,7 @@ If the server has a preferred choice, it should generate a Location header. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/300`, }, { - Code: "301", + Name: "301", Summary: "Moved Permanently", Description: `The HyperText Transfer Protocol (HTTP) 301 Moved Permanently redirect status response code indicates that the resource requested has been definitively moved to the URL given by the Location headers. A browser redirects to this page and search engines update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is sent to the new URL). @@ -179,7 +179,7 @@ Even if the specification requires the method (and the body) not to be altered w https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301`, }, { - Code: "302", + Name: "302", Summary: "Found", Description: `The HyperText Transfer Protocol (HTTP) 302 Found redirect status response code indicates that the resource requested has been temporarily moved to the URL given by the Location header. A browser redirects to this page but search engines don't update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is not sent to the new URL). @@ -190,14 +190,14 @@ In the cases where you want the method used to be changed to GET, use 303 See Ot https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302`, }, { - Code: "303", + Name: "303", Summary: "See other", Description: `The HyperText Transfer Protocol (HTTP) 303 See Other redirect status response code indicates that the redirects don't link to the newly uploaded resources, but to another page (such as a confirmation page or an upload progress page). This response code is usually sent back as a result of PUT or POST. The method used to display this redirected page is always GET. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/303`, }, { - Code: "304", + Name: "304", Summary: "Not Modified", Description: `The HTTP 304 Not Modified client redirection response code indicates that there is no need to retransmit the requested resources. It is an implicit redirection to a cached resource. This happens when the request method is safe, like a GET or a HEAD request, or when the request is conditional and uses a If-None-Match or a If-Modified-Since header. @@ -206,21 +206,21 @@ The equivalent 200 OK response would have included the headers Cache-Control, Co https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304`, }, { - Code: "305", + Name: "305", Summary: "Use proxy", Description: `Defined in a previous version of the HTTP specification to indicate that a requested response must be accessed by a proxy. It has been deprecated due to security concerns regarding in-band configuration of a proxy. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status`, }, { - Code: "306", + Name: "306", Summary: "unused", Description: `This response code is no longer used; it is just reserved. It was used in a previous version of the HTTP/1.1 specification. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status`, }, { - Code: "307", + Name: "307", Summary: "Temporary redirect", Description: `HTTP 307 Temporary Redirect redirect status response code indicates that the resource requested has been temporarily moved to the URL given by the Location headers. @@ -231,7 +231,7 @@ The only difference between 307 and 302 is that 307 guarantees that the method a https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307`, }, { - Code: "308", + Name: "308", Summary: "Permanent redirect", Description: `The HyperText Transfer Protocol (HTTP) 308 Permanent Redirect redirect status response code indicates that the resource requested has been definitively moved to the URL given by the Location headers. A browser redirects to this page and search engines update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is sent to the new URL). @@ -240,20 +240,20 @@ The request method and the body will not be altered, whereas 301 may incorrectly https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308`, }, { - Code: "4xx", + Name: "4xx", Summary: "Client error responses", Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Status https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_errors`, }, { - Code: "400", + Name: "400", Summary: "Bad request", Description: `The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing). https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400`, }, { - Code: "401", + Name: "401", Summary: "Unauthorized", Description: `The HTTP 401 Unauthorized client error status response code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. @@ -264,7 +264,7 @@ This status is similar to 403, but in this case, authentication is possible. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401`, }, { - Code: "402", + Name: "402", Summary: "Payment required", Description: `The HTTP 402 Payment Required is a nonstandard client error status response code that is reserved for future use. @@ -273,7 +273,7 @@ Sometimes, this code indicates that the request can not be processed until the c https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402`, }, { - Code: "403", + Name: "403", Summary: "Forbidden", Description: `The HTTP 403 Forbidden client error status response code indicates that the server understood the request but refuses to authorize it. @@ -282,7 +282,7 @@ This status is similar to 401, but in this case, re-authenticating will make no https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403`, }, { - Code: "404", + Name: "404", Summary: "Not found", Description: `The HTTP 404 Not Found client error response code indicates that the server can't find the requested resource. Links which lead to a 404 page are often called broken or dead links, and can be subject to link rot. @@ -291,7 +291,7 @@ A 404 status code does not indicate whether the resource is temporarily or perma https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404`, }, { - Code: "405", + Name: "405", Summary: "Method not allowed", Description: `The HyperText Transfer Protocol (HTTP) 405 Method Not Allowed response status code indicates that the request method is known by the server but is not supported by the target resource. @@ -300,7 +300,7 @@ The server MUST generate an Allow header field in a 405 response containing a li https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405`, }, { - Code: "406", + Name: "406", Summary: "Not acceptable", Description: `The HyperText Transfer Protocol (HTTP) 406 Not Acceptable client error response code indicates that the server cannot produce a response matching the list of acceptable values defined in the request's proactive content negotiation headers, and that the server is unwilling to supply a default representation. @@ -318,7 +318,7 @@ If a server returns such an error status, the body of the message should contain https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406`, }, { - Code: "407", + Name: "407", Summary: "Proxy authentication required", Description: `The HTTP 407 Proxy Authentication Required client error status response code indicates that the request has not been applied because it lacks valid authentication credentials for a proxy server that is between the browser and the server that can access the requested resource. @@ -327,7 +327,7 @@ This status is sent with a Proxy-Authenticate header that contains information o https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/407`, }, { - Code: "408", + Name: "408", Summary: "Request timeout", Description: `The HyperText Transfer Protocol (HTTP) 408 Request Timeout response status code means that the server would like to shut down this unused connection. It is sent on an idle connection by some servers, even without any previous request by the client. @@ -338,7 +338,7 @@ This response is used much more since some browsers, like Chrome, Firefox 27+, a https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/408`, }, { - Code: "409", + Name: "409", Summary: "Conflict", Description: `The HTTP 409 Conflict response status code indicates a request conflict with current state of the server. @@ -347,7 +347,7 @@ Conflicts are most likely to occur in response to a PUT request. For example, yo https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/409`, }, { - Code: "410", + Name: "410", Summary: "Gone", Description: `The HyperText Transfer Protocol (HTTP) 410 Gone client error response code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent. @@ -356,28 +356,28 @@ If you don't know whether this condition is temporary or permanent, a 404 status https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/410`, }, { - Code: "411", + Name: "411", Summary: "Length required", Description: `The HyperText Transfer Protocol (HTTP) 411 Length Required client error response code indicates that the server refuses to accept the request without a defined Content-Length header. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/411`, }, { - Code: "412", + Name: "412", Summary: "Precondition failed", Description: `The HyperText Transfer Protocol (HTTP) 412 Precondition Failed client error response code indicates that access to the target resource has been denied. This happens with conditional requests on methods other than GET or HEAD when the condition defined by the If-Unmodified-Since or If-None-Match headers is not fulfilled. In that case, the request, usually an upload or a modification of a resource, cannot be made and this error response is sent back. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412`, }, { - Code: "413", + Name: "413", Summary: "Payload too large", Description: `The HTTP 413 Payload Too Large response status code indicates that the request entity is larger than limits defined by server; the server might close the connection or return a Retry-After header field. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/413`, }, { - Code: "414", + Name: "414", Summary: "URI too long", Description: `The HTTP 414 URI Too Long response status code indicates that the URL requested by the client is longer than the server is willing to interpret. @@ -390,7 +390,7 @@ There are a few conditions when this might occur: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/414`, }, { - Code: "415", + Name: "415", Summary: "Unsupported media type", Description: `The HTTP 415 Unsupported Media Type client error response code indicates that the server refuses to accept the request because the payload format is in an unsupported format. @@ -399,7 +399,7 @@ The format problem might be due to the request's indicated Content-Type or Conte https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415`, }, { - Code: "416", + Name: "416", Summary: "Range not satisfiable", Description: `The HyperText Transfer Protocol (HTTP) 416 Range Not Satisfiable error response code indicates that a server cannot serve the requested ranges. The most likely reason is that the document doesn't contain such ranges, or that the Range header value, though syntactically correct, doesn't make sense. @@ -410,7 +410,7 @@ Faced with this error, browsers usually either abort the operation (for example, https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416`, }, { - Code: "417", + Name: "417", Summary: "Expectation failed", Description: `The HTTP 417 Expectation Failed client error response code indicates that the expectation given in the request's Expect header could not be met. @@ -419,49 +419,49 @@ See the Expect header for more details. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/417`, }, { - Code: "418", + Name: "418", Summary: "I'm a teapot", Description: `The HTTP 418 I'm a teapot client error response code indicates that the server refuses to brew coffee because it is a teapot. This error is a reference to Hyper Text Coffee Pot Control Protocol which was an April Fools' joke in 1998. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418`, }, { - Code: "421", + Name: "421", Summary: "Misdirected Request", Description: `The request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status`, }, { - Code: "422", + Name: "422", Summary: "Unprocessable Entity (WebDAV)", Description: `The HyperText Transfer Protocol (HTTP) 422 Unprocessable Entity response status code indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422`, }, { - Code: "423", + Name: "423", Summary: "Locked (WebDAV)", Description: `The resource that is being accessed is locked. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status`, }, { - Code: "424", + Name: "424", Summary: "Failed Dependency (WebDAV)", Description: `The request failed due to failure of a previous request. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status`, }, { - Code: "425", + Name: "425", Summary: "Too early", Description: `The HyperText Transfer Protocol (HTTP) 425 Too Early response status code indicates that the server is unwilling to risk processing a request that might be replayed, which creates the potential for a replay attack. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/425`, }, { - Code: "426", + Name: "426", Summary: "Upgrade required", Description: `The HTTP 426 Upgrade Required client error response code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. @@ -470,7 +470,7 @@ The server sends an Upgrade header with this response to indicate the required p https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/426`, }, { - Code: "428", + Name: "428", Summary: "Precondition required", Description: `The HTTP 428 Precondition Required response status code indicates that the server requires the request to be conditional. @@ -481,7 +481,7 @@ When a precondition header is not matching the server side state, the response s https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/428`, }, { - Code: "429", + Name: "429", Summary: "Too many requests", Description: `The HTTP 429 Too Many Requests response status code indicates the user has sent too many requests in a given amount of time ("rate limiting"). @@ -490,7 +490,7 @@ A Retry-After header might be included to this response indicating how long to w https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429`, }, { - Code: "431", + Name: "431", Summary: "Request Header Fields Too Large", Description: `The HTTP 431 Request Header Fields Too Large response status code indicates that the server refuses to process the request because the request’s HTTP headers are too long. The request may be resubmitted after reducing the size of the request headers. @@ -504,20 +504,20 @@ Servers will often produce this status if: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431`, }, { - Code: "451", + Name: "451", Summary: "Unavailable For Legal Reasons", Description: `The HyperText Transfer Protocol (HTTP) 451 Unavailable For Legal Reasons client error response code indicates that the user requested a resource that is not available due to legal reasons, such as a web page for which a legal action has been issued. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/451`, }, { - Code: "5xx", + Name: "5xx", Summary: "Server error responses", Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Status https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_errors`, }, { - Code: "500", + Name: "500", Summary: "Internal server error", Description: `The HyperText Transfer Protocol (HTTP) 500 Internal Server Error server error response code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. @@ -526,7 +526,7 @@ This error response is a generic "catch-all" response. Usually, this indicates t https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/500`, }, { - Code: "501", + Name: "501", Summary: "Not implemented", Description: `The HyperText Transfer Protocol (HTTP) 501 Not Implemented server error response code means that the server does not support the functionality required to fulfill the request. @@ -539,14 +539,14 @@ If the server does recognize the method, but intentionally does not support it, https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/501`, }, { - Code: "502", + Name: "502", Summary: "Bad gateway", Description: `The HyperText Transfer Protocol (HTTP) 502 Bad Gateway server error response code indicates that the server, while acting as a gateway or proxy, received an invalid response from the upstream server. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/502`, }, { - Code: "503", + Name: "503", Summary: "Service unavailable", Description: `The HyperText Transfer Protocol (HTTP) 503 Service Unavailable server error response code indicates that the server is not ready to handle the request. @@ -555,21 +555,21 @@ Common causes are a server that is down for maintenance or that is overloaded. T https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503`, }, { - Code: "504", + Name: "504", Summary: "Gateway timeout", Description: `The HyperText Transfer Protocol (HTTP) 504 Gateway Timeout server error response code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server that it needed in order to complete the request. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/504`, }, { - Code: "505", + Name: "505", Summary: "HTTP version no supported", Description: `The HyperText Transfer Protocol (HTTP) 505 HTTP Version Not Supported response status code indicates that the HTTP version used in the request is not supported by the server. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/505`, }, { - Code: "506", + Name: "506", Summary: "Variant also negotiates", Description: `The HyperText Transfer Protocol (HTTP) 506 Variant Also Negotiates response status code may be given in the context of Transparent Content Negotiation (see RFC 2295). This protocol enables a client to retrieve the best variant of a given resource, where the server supports multiple variants. @@ -578,7 +578,7 @@ The Variant Also Negotiates status code indicates an internal server configurati https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/506`, }, { - Code: "507", + Name: "507", Summary: "Insufficient Storage (WebDAV)", Description: `The HyperText Transfer Protocol (HTTP) 507 Insufficient Storage response status code may be given in the context of the Web Distributed Authoring and Versioning (WebDAV) protocol (see RFC 4918). @@ -588,7 +588,7 @@ the representation needed to successfully complete the request. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/507`, }, { - Code: "508", + Name: "508", Summary: "Loop Detected (WebDAV)", Description: `The HyperText Transfer Protocol (HTTP) 508 Loop Detected response status code may be given in the context of the Web Distributed Authoring and Versioning (WebDAV) protocol. @@ -597,7 +597,7 @@ It indicates that the server terminated an operation because it encountered an i https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/508`, }, { - Code: "510", + Name: "510", Summary: "Not extended", Description: `The HyperText Transfer Protocol (HTTP) 510 Not Extended response status code is sent in the context of the HTTP Extension Framework, defined in RFC 2774. @@ -606,7 +606,7 @@ In that specification a client may send a request that contains an extension dec https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/510`, }, { - Code: "511", + Name: "511", Summary: "Network Authentication Required", Description: `The HTTP 511 Network Authentication Required response status code indicates that the client needs to authenticate to gain network access. diff --git a/httpref_test.go b/httpref_test.go index 3cab125..a1a866e 100644 --- a/httpref_test.go +++ b/httpref_test.go @@ -7,7 +7,7 @@ import ( func Test_Anything(t *testing.T) { } -func TestStatusRefs_ByCode(t *testing.T) { +func TestReferences_ByName(t *testing.T) { type args struct { code string } @@ -22,8 +22,8 @@ func TestStatusRefs_ByCode(t *testing.T) { for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { - if got := Statuses.ByCode(tt.name); len(got) != tt.want { - t.Errorf("StatusRefs.ByCode() = %v, want %v", len(got), tt.want) + if got := Statuses.ByName(tt.name); len(got) != tt.want { + t.Errorf("References.ByName() = %v, want %v", len(got), tt.want) } }) } From 3ced6311c991c0724d80c011681c95e6ee277f9b Mon Sep 17 00:00:00 2001 From: Pascal Dennerly Date: Sun, 12 Jan 2020 15:00:34 +0000 Subject: [PATCH 2/7] Add support marking a reference as a title --- cmd/root.go | 13 +++++++++---- httpref.go | 18 ++++++++++++++++++ 2 files changed, 27 insertions(+), 4 deletions(-) diff --git a/cmd/root.go b/cmd/root.go index 31fb972..216438a 100644 --- a/cmd/root.go +++ b/cmd/root.go @@ -34,17 +34,24 @@ func init() { } func root(cmd *cobra.Command, args []string) error { - results := httpref.Statuses + results := append(httpref.Statuses.Titles(), httpref.Headers.Titles()...) if !all { if len(args) == 0 { - fmt.Fprintf(os.Stderr, "Must specify a status code, or part of it\n") + fmt.Fprintf(os.Stderr, "Must specify something to filter by\n") os.Exit(1) } else { + results = append(httpref.Statuses, httpref.Headers...) results = results.ByName(args[0]) } } + printResults(results) + + return nil +} + +func printResults(results httpref.References) { switch len(results) { case 0: fmt.Fprintf(os.Stderr, "Name note recognised\n") @@ -56,6 +63,4 @@ func root(cmd *cobra.Command, args []string) error { fmt.Printf("\t%s\t%s\n", r.Name, r.Summary) } } - - return nil } diff --git a/httpref.go b/httpref.go index 54c53bd..57073c3 100644 --- a/httpref.go +++ b/httpref.go @@ -4,6 +4,7 @@ import "strings" type Reference struct { Name string + IsTitle bool Summary string Description string } @@ -22,9 +23,22 @@ func (r References) ByName(code string) References { return results } +func (r References) Titles() References { + results := References{} + + for _, v := range r { + if v.IsTitle { + results = append(results, v) + } + } + + return results +} + var Statuses = References{ { Name: "1xx", + IsTitle: true, Summary: "Informational response", Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Status https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#1xx_Informational_response`, @@ -61,6 +75,7 @@ https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103`, }, { Name: "2xx", + IsTitle: true, Summary: "Successful responses", Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Status https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#2xx_Success`, @@ -156,6 +171,7 @@ https://developer.mozilla.org/en-US/docs/Web/HTTP/Status`, }, { Name: "3xx", + IsTitle: true, Summary: "Redirection messages", Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Status https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection`, @@ -241,6 +257,7 @@ https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308`, }, { Name: "4xx", + IsTitle: true, Summary: "Client error responses", Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Status https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_errors`, @@ -512,6 +529,7 @@ https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/451`, }, { Name: "5xx", + IsTitle: true, Summary: "Server error responses", Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Status https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_errors`, From b9de6d17a74073f02249fe5cb208c264d8b1e3de Mon Sep 17 00:00:00 2001 From: Pascal Dennerly Date: Sun, 12 Jan 2020 15:08:14 +0000 Subject: [PATCH 3/7] Add specific status only search --- cmd/status.go | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 cmd/status.go diff --git a/cmd/status.go b/cmd/status.go new file mode 100644 index 0000000..3898fa9 --- /dev/null +++ b/cmd/status.go @@ -0,0 +1,45 @@ +/* +Copyright © 2020 NAME HERE + +Licensed under the Apache License, Version 2.0 (the "License"); +you may not use this file except in compliance with the License. +You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, software +distributed under the License is distributed on an "AS IS" BASIS, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +See the License for the specific language governing permissions and +limitations under the License. +*/ +package cmd + +import ( + "github.com/dnnrly/httpref" + "github.com/spf13/cobra" +) + +// statusCmd represents the status command +var statusCmd = &cobra.Command{ + Use: "status", + Short: "References for HTTP status codes", + Long: `This displays useful information related to HTTP. + +Most of the content comes from the Mozilla developer documentation (https://developer.mozilla.org/en-US/docs/Web/HTTP) and is copyright Mozilla and individual contributors. See https://developer.mozilla.org/en-US/docs/MDN/About#Copyrights_and_licenses for details.`, + Run: func(cmd *cobra.Command, args []string) { + results := httpref.Statuses + + if len(args) == 0 { + results = results.Titles() + } else { + results = results.ByName(args[0]) + } + + printResults(results) + }, +} + +func init() { + rootCmd.AddCommand(statusCmd) +} From 4f98cbc7a152acf948900818e4f73e8669c1b598 Mon Sep 17 00:00:00 2001 From: Pascal Dennerly Date: Sun, 12 Jan 2020 15:27:42 +0000 Subject: [PATCH 4/7] Add start of support for headers commands --- cmd/headers.go | 46 ++++++++++++++++++++++++++++++++++++++++++++++ cmd/status.go | 2 +- 2 files changed, 47 insertions(+), 1 deletion(-) create mode 100644 cmd/headers.go diff --git a/cmd/headers.go b/cmd/headers.go new file mode 100644 index 0000000..4808c13 --- /dev/null +++ b/cmd/headers.go @@ -0,0 +1,46 @@ +/* +Copyright © 2020 NAME HERE + +Licensed under the Apache License, Version 2.0 (the "License"); +you may not use this file except in compliance with the License. +You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, software +distributed under the License is distributed on an "AS IS" BASIS, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +See the License for the specific language governing permissions and +limitations under the License. +*/ +package cmd + +import ( + "github.com/dnnrly/httpref" + "github.com/spf13/cobra" +) + +// headersCmd represents the headers command +var headersCmd = &cobra.Command{ + Use: "headers", + Aliases: []string{"header"}, + Short: "References for common HTTP headers", + Long: `This displays useful information related to HTTP. + +Most of the content comes from the Mozilla developer documentation (https://developer.mozilla.org/en-US/docs/Web/HTTP) and is copyright Mozilla and individual contributors. See https://developer.mozilla.org/en-US/docs/MDN/About#Copyrights_and_licenses for details.`, + Run: func(cmd *cobra.Command, args []string) { + results := httpref.Headers + + if len(args) == 0 { + results = results.Titles() + } else { + results = results.ByName(args[0]) + } + + printResults(results) + }, +} + +func init() { + rootCmd.AddCommand(headersCmd) +} diff --git a/cmd/status.go b/cmd/status.go index 3898fa9..cbcacda 100644 --- a/cmd/status.go +++ b/cmd/status.go @@ -22,7 +22,7 @@ import ( // statusCmd represents the status command var statusCmd = &cobra.Command{ - Use: "status", + Use: "status [filter]", Short: "References for HTTP status codes", Long: `This displays useful information related to HTTP. From de6acdbc2fdfa933acf89dcf1c745e936ba7adf9 Mon Sep 17 00:00:00 2001 From: Pascal Dennerly Date: Sun, 12 Jan 2020 21:17:22 +0000 Subject: [PATCH 5/7] Add references for common headers --- headers.go | 1192 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1192 insertions(+) create mode 100644 headers.go diff --git a/headers.go b/headers.go new file mode 100644 index 0000000..314294c --- /dev/null +++ b/headers.go @@ -0,0 +1,1192 @@ +package httpref + +var Headers = References{ + { + Name: "Headers", + IsTitle: true, + Summary: "Guidance about headers", + Description: `HTTP headers let the client and the server pass additional information with an HTTP request or response. An HTTP header consists of its case-insensitive name followed by a colon (:), then by its value. Whitespace before the value is ignored. + +Custom proprietary headers have historically been used with an X- prefix, but this convention was deprecated in June 2012 because of the inconveniences it caused when nonstandard fields became standard in RFC 6648; others are listed in an IANA registry, whose original content was defined in RFC 4229. IANA also maintains a registry of proposed new HTTP headers. + +Headers can be grouped according to their contexts: + + General headers apply to both requests and responses, but with no relation to the data transmitted in the body. + Request headers contain more information about the resource to be fetched, or about the client requesting the resource. + Response headers hold additional information about the response, like its location or about the server providing it. + Entity headers contain information about the body of the resource, like its content length or MIME type. + +Headers can also be grouped according to how proxies handle them: + + Connection + Keep-Alive + Proxy-Authenticate + Proxy-Authorization + TE + Trailer + Transfer-Encoding + Upgrade. + +End-to-end headers + These headers must be transmitted to the final recipient of the message: the server for a request, or the client for a response. Intermediate proxies must retransmit these headers unmodified and caches must store them. +Hop-by-hop headers + These headers are meaningful only for a single transport-level connection, and must not be retransmitted by proxies or cached. Note that only hop-by-hop headers may be set using the Connection general header. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers`, + }, + { + Name: "Authentication", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Authentication", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Authentication`, + }, + { + Name: "WWW-Authenticate", + Summary: "Defines the authentication method that should be used to access a resource.", + Description: `The HTTP WWW-Authenticate response header defines the authentication method that should be used to gain access to a resource. + +The WWW-Authenticate header is sent along with a 401 Unauthorized response. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate`, + }, + { + Name: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization", + Summary: "Contains the credentials to authenticate a user-agent with a server.", + Description: `The HTTP Authorization request header contains the credentials to authenticate a user agent with a server, usually after the server has responded with a 401 Unauthorized status and the WWW-Authenticate header. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization`, + }, + { + Name: "Proxy-Authenticate", + Summary: "Defines the authentication method that should be used to access a resource behind a proxy server.", + Description: `The HTTP Proxy-Authenticate response header defines the authentication method that should be used to gain access to a resource behind a proxy server. It authenticates the request to the proxy server, allowing it to transmit the request further. + +The Proxy-Authenticate header is sent along with a 407 Proxy Authentication Required. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authenticate`, + }, + { + Name: "Caching", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Caching", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Caching`, + }, + { + Name: "Age", + Summary: "The time, in seconds, that the object has been in a proxy cache.", + Description: `The Age header contains the time in seconds the object has been in a proxy cache. + +The Age header is usually close to zero. If it is Age: 0, it was probably just fetched from the origin server; otherwise It is usually calculated as a difference between the proxy's current date and the Date general header included in the HTTP response. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Age`, + }, + { + Name: "Cache-Control", + Summary: "Directives for caching mechanisms in both requests and responses.", + Description: `The Cache-Control HTTP header holds directives (instructions) for caching in both requests and responses. A given directive in a request does not mean the same directive should be in the response. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control`, + }, + { + Name: "Clear-Site-Data", + Summary: "Clears browsing data (e.g. cookies, storage, cache) associated with the requesting website.", + Description: `The Clear-Site-Data header clears browsing data (cookies, storage, cache) associated with the requesting website. It allows web developers to have more control over the data stored locally by a browser for their origins. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data`, + }, + { + Name: "Expires", + Summary: "The date/time after which the response is considered stale.", + Description: `The Expires header contains the date/time after which the response is considered stale. + +Invalid dates, like the value 0, represent a date in the past and mean that the resource is already expired. +If there is a Cache-Control header with the max-age or s-maxage directive in the response, the Expires header is ignored. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires`, + }, + { + Name: "Pragma", + Summary: "Implementation-specific header that may have various effects anywhere along the request-response chain. Used for backwards compatibility with HTTP/1.0 caches where the Cache-Control header is not yet present.", + Description: `The Pragma HTTP/1.0 general header is an implementation-specific header that may have various effects along the request-response chain. It is used for backwards compatibility with HTTP/1.0 caches where the Cache-Control HTTP/1.1 header is not yet present. + +Note: Pragma is not specified for HTTP responses and is therefore not a reliable replacement for the general HTTP/1.1 Cache-Control header, although it does behave the same as Cache-Control: no-cache, if the Cache-Control header field is omitted in a request. Use Pragma only for backwards compatibility with HTTP/1.0 clients. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Pragma`, + }, + { + Name: "Warning", + Summary: "General warning information about possible problems.", + Description: ` + +Note: The Warning header is soon to be deprecated; see Warning (https://github.com/httpwg/http-core/issues/139) and Warning: header & stale-while-revalidate (https://github.com/whatwg/fetch/issues/913) for more details. + +The Warning general HTTP header contains information about possible problems with the status of the message. More than one Warning header may appear in a response. + +Warning header fields can in general be applied to any message, however some warn-codes are specific to caches and can only be applied to response messages. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Warning`, + }, + { + Name: "Client hints", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Client_hints", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Client_hints`, + }, + { + Name: "Accept-CH", + Summary: "Servers can advertise support for Client Hints using the Accept-CH header field or an equivalent HTML element with http-equiv attribute ([HTML5]).", + Description: `Secure context +This feature is available only in secure contexts (HTTPS), in some or all supporting browsers. + +This is an experimental technology +Check the Browser compatibility table carefully before using this in production. + +The Accept-CH header is set by the server to specify which Client Hints headers client should include in subsequent requests. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH`, + }, + { + Name: "Accept-CH-Lifetime", + Summary: "Servers can ask the client to remember the set of Client Hints that the server supports for a specified period of time, to enable delivery of Client Hints on subsequent requests to the server’s origin ([RFC6454]).", + Description: `The Accept-CH-Lifetime header is set by the server to specify the persistence of Accept-CH header value that specifies for which Client Hints headers client should include in subsequent requests. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH-Lifetime`, + }, + { + Name: "Early-Data", + Summary: "Indicates that the request has been conveyed in early data.", + Description: `The Early-Data header is set by an intermediate to indicate that the request has been conveyed in TLS early data, and additionally indicates that an intermediary understands the 425 (Too Early) status code. The Early-Data header is not set by the originator of the request (i.e., a browser). + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Early-Data`, + }, + { + Name: "Content-DPR", + Summary: "A number that indicates the ratio between physical pixels over CSS pixels of the selected image response.", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Client_hints`, + }, + { + Name: "DPR", + Summary: "A number that indicates the client’s current Device Pixel Ratio (DPR), which is the ratio of physical pixels over CSS pixels (Section 5.2 of [CSSVAL]) of the layout viewport (Section 9.1.1 of [CSS2]) on the device.", + Description: `The DPR header is a Client Hints headers which represents the client device pixel ratio (DPR), which is the the number of physical device pixels corresponding to every CSS pixel. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DPR`, + }, + { + Name: "Device-Memory", + Summary: "Technically a part of Device Memory API, this header represents an approximate amount of RAM client has.", + Description: `The Device-Memory header is a Device Memory API header that works like Client Hints header which represents the approximate amount of RAM client device has. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Device-Memory`, + }, + { + Name: "Save-Data", + Summary: "A boolean that indicates the user agent's preference for reduced data usage.", + Description: `The Save-Data header field is a boolean which, in requests, indicates the client's preference for reduced data usage. This could be for reasons such as high transfer costs, slow connection speeds, etc. + +A value of On indicates explicit user opt-in into a reduced data usage mode on the client, and when communicated to origins allows them to deliver alternative content to reduce the data downloaded such as smaller image and video resources, different markup and styling, disabled polling and automatic updates, and so on. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data`, + }, + { + Name: "Viewport-Width", + Summary: "A number that indicates the layout viewport width in CSS pixels. The provided pixel value is a number rounded to the smallest following integer (i.e. ceiling value).", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Client_hints`, + }, + { + Name: "Viewport-Width", + Summary: "A number that indicates the layout viewport width in CSS pixels. The provided pixel value is a number rounded to the smallest following integer (i.e. ceiling value).", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Client_hints`, + }, + { + Name: "Width", + Summary: "The Width request header field is a number that indicates the desired resource width in physical pixels (i.e. intrinsic size of an image).", + Description: ` + + The Width request header field is a number that indicates the desired resource width in physical pixels (i.e. intrinsic size of an image). The provided pixel value is a number rounded to the smallest following integer (i.e. ceiling value). + + If the desired resource width is not known at the time of the request or the resource does not have a display width, the Width header field can be omitted. If Width occurs in a message more than once, the last value overrides all previous occurrences + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Client_hints`, + }, + { + Name: "Conditionals", + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Conditionals", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Conditionals`, + }, + { + Name: "Last-Modified", + Summary: "The last modification date of the resource, used to compare several versions of the same resource. It is less accurate than ETag, but easier to calculate in some environments. Conditional requests using If-Modified-Since and If-Unmodified-Since use this value to change the behavior of the request.", + Description: `The Last-Modified response HTTP header contains the date and time at which the origin server believes the resource was last modified. It is used as a validator to determine if a resource received or stored is the same. Less accurate than an ETag header, it is a fallback mechanism. Conditional requests containing If-Modified-Since or If-Unmodified-Since headers make use of this field. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified`, + }, + { + Name: "ETag", + Summary: "A unique string identifying the version of the resource. Conditional requests using If-Match and If-None-Match use this value to change the behavior of the request.", + Description: `The ETag HTTP response header is an identifier for a specific version of a resource. It lets caches be more efficient and save bandwidth, as a web server does not need to resend a full response if the content has not changed. Additionally, etags help prevent simultaneous updates of a resource from overwriting each other ("mid-air collisions"). + +If the resource at a given URL changes, a new Etag value must be generated. A comparison of them can determine whether two representations of a resource are the same. Etags are therefore similar to fingerprints, and might also be used for tracking purposes by some servers. They might also be set to persist indefinitely by a tracking server. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag`, + }, + { + Name: "If-Match", + Summary: "Makes the request conditional, and applies the method only if the stored resource matches one of the given ETags.", + Description: `The If-Match HTTP request header makes the request conditional. For GET and HEAD methods, the server will send back the requested resource only if it matches one of the listed ETags. For PUT and other non-safe methods, it will only upload the resource in this case. + +The comparison with the stored ETag uses the strong comparison algorithm, meaning two files are considered identical byte to byte only. If a listed ETag has the W/ prefix indicating a weak entity tag, it will never match under this comparison algorithm. + +There are two common use cases: + + For GET and HEAD methods, used in combination with a Range header, it can guarantee that the new ranges requested comes from the same resource than the previous one. If it doesn't match, then a 416 (Range Not Satisfiable) response is returned. + For other methods, and in particular for PUT, If-Match can be used to prevent the lost update problem. It can check if the modification of a resource that the user wants to upload will not override another change that has been done since the original resource was fetched. If the request cannot be fulfilled, the 412 (Precondition Failed) response is returned. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match`, + }, + { + Name: "If-None-Match", + Summary: "Makes the request conditional, and applies the method only if the stored resource doesn't match any of the given ETags. This is used to update caches (for safe requests), or to prevent to upload a new resource when one already exists.", + Description: `The If-None-Match HTTP request header makes the request conditional. For GET and HEAD methods, the server will send back the requested resource, with a 200 status, only if it doesn't have an ETag matching the given ones. For other methods, the request will be processed only if the eventually existing resource's ETag doesn't match any of the values listed. + +When the condition fails for GET and HEAD methods, then the server must return HTTP status code 304 (Not Modified). For methods that apply server-side changes, the status code 412 (Precondition Failed) is used. Note that the server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary. + +The comparison with the stored ETag uses the weak comparison algorithm, meaning two files are considered identical if the content is equivalent — they don't have to be identical byte for byte. For example, two pages that differ by the date of generation in the footer would still be considered as identical. + +When used in combination with If-Modified-Since, If-None-Match has precedence (if the server supports it). + +There are two common use cases: + + For GET and HEAD methods, to update a cached entity that has an associated ETag. + For other methods, and in particular for PUT, If-None-Match used with the * value can be used to save a file not known to exist, guaranteeing that another upload didn't happen before, losing the data of the previous put; this problem is a variation of the lost update problem. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match`, + }, + { + Name: "If-Modified-Since", + Summary: "Makes the request conditional, and expects the entity to be transmitted only if it has been modified after the given date. This is used to transmit data only when the cache is out of date.", + Description: `The If-Modified-Since request HTTP header makes the request conditional: the server will send back the requested resource, with a 200 status, only if it has been last modified after the given date. If the request has not been modified since, the response will be a 304 without any body; the Last-Modified response header of a previous request will contain the date of last modification. Unlike If-Unmodified-Since, If-Modified-Since can only be used with a GET or HEAD. + +When used in combination with If-None-Match, it is ignored, unless the server doesn't support If-None-Match. + +The most common use case is to update a cached entity that has no associated ETag. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since`, + }, + { + Name: "If-Unmodified-Since", + Summary: "Makes the request conditional, and expects the entity to be transmitted only if it has not been modified after the given date. This ensures the coherence of a new fragment of a specific range with previous ones, or to implement an optimistic concurrency control system when modifying existing documents.", + Description: `The If-Unmodified-Since request HTTP header makes the request conditional: the server will send back the requested resource, or accept it in the case of a POST or another non-safe method, only if it has not been last modified after the given date. If the resource has been modified after the given date, the response will be a 412 (Precondition Failed) error. + +There are two common use cases: + + In conjunction with non-safe methods, like POST, it can be used to implement an optimistic concurrency control, like done by some wikis: editions are rejected if the stored document has been modified since the original has been retrieved. + In conjunction with a range request with a If-Range header, it can be used to ensure that the new fragment requested comes from an unmodified document. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since`, + }, + { + Name: "Vary", + Summary: "Determines how to match request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server.", + Description: `The Vary HTTP response header determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server. It is used by the server to indicate which headers it used when selecting a representation of a resource in a content negotiation algorithm. + +The Vary header should be set on a 304 Not Modified response exactly like it would have been set on an equivalent 200 OK response. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary`, + }, + { + Name: "Connection management", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Connection_management", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Connection_management`, + }, + { + Name: "Connection", + Summary: "Controls whether the network connection stays open after the current transaction finishes.", + Description: `The Connection general header controls whether or not the network connection stays open after the current transaction finishes. If the value sent is keep-alive, the connection is persistent and not closed, allowing for subsequent requests to the same server to be done. +Connection-specific header fields such as Connection must not be used with HTTP/2. + +Except for the standard hop-by-hop headers (Keep-Alive, Transfer-Encoding, TE, Connection, Trailer, Upgrade, Proxy-Authorization and Proxy-Authenticate), any hop-by-hop headers used by the message must be listed in the Connection header, so that the first proxy knows it has to consume them and not forward them further. Standard hop-by-hop headers can be listed too (it is often the case of Keep-Alive, but this is not mandatory). + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection`, + }, + { + Name: "Keep-Alive", + Summary: "Controls how long a persistent connection should stay open.", + Description: `The Keep-Alive general header allows the sender to hint about how the connection may be used to set a timeout and a maximum amount of requests. + +The Connection header needs to be set to "keep-alive" for this header to have any meaning. Also, Connection and Keep-Alive are ignored in HTTP/2; connection management is handled by other mechanisms there. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive`, + }, + { + Name: "Content negotiation", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation", + Description: `In HTTP, content negotiation is the mechanism that is used for serving different representations of a resource at the same URI, so that the user agent can specify which is best suited for the user (for example, which language of a document, which image format, or which content encoding). + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation`, + }, + { + Name: "Accept", + Summary: "Informs the server about the types of data that can be sent back.", + Description: `The Accept request HTTP header advertises which content types, expressed as MIME types, the client is able to understand. Using content negotiation, the server then selects one of the proposals, uses it and informs the client of its choice with the Content-Type response header. Browsers set adequate values for this header depending on the context where the request is done: when fetching a CSS stylesheet a different value is set for the request than when fetching an image, video or a script. + + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept`, + }, + { + Name: "Accept-Charset", + Summary: "Which character encodings the client understands.", + Description: `The Accept-Charset request HTTP header advertises which character encodings the client understands. Using content negotiation, the server selects one of the encodings, uses it, and informs the client of its choice within the Content-Type response header, usually in a charset= parameter. Browsers usually don't send this header, as the default value for each resource is usually correct and transmitting it would allow fingerprinting. + +If the server cannot serve any character encoding from this request header, it can theoretically send back a 406 Not Acceptable error code. But for a better user experience, this is rarely done and the Accept-Charset header is ignored. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Charset`, + }, + { + Name: "Accept-Encoding", + Summary: "The encoding algorithm, usually a compression algorithm, that can be used on the resource sent back.", + Description: `The Accept-Encoding request HTTP header advertises which content encoding, usually a compression algorithm, the client is able to understand. Using content negotiation, the server selects one of the proposals, uses it and informs the client of its choice with the Content-Encoding response header. + +Even if both the client and the server supports the same compression algorithms, the server may choose not to compress the body of a response, if the identity value is also acceptable. Two common cases lead to this: + + The data to be sent is already compressed and a second compression won't lead to smaller data to be transmitted. This may be the case with some image formats; + The server is overloaded and cannot afford the computational overhead induced by the compression requirement. Typically, Microsoft recommends not to compress if a server uses more than 80% of its computational power. + +As long as the identity value, meaning no encoding, is not explicitly forbidden, by an identity;q=0 or a *;q=0 without another explicitly set value for identity, the server must never send back a 406 Not Acceptable error. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding`, + }, + { + Name: "Accept-Language", + Summary: "Informs the server about the human language the server is expected to send back. This is a hint and is not necessarily under the full control of the user: the server should always pay attention not to override an explicit user choice (like selecting a language from a dropdown).", + Description: `The Accept-Language request HTTP header advertises which languages the client is able to understand, and which locale variant is preferred. (By languages, we mean natural languages, such as English, and not programming languages.) Using content negotiation, the server then selects one of the proposals, uses it and informs the client of its choice with the Content-Language response header. Browsers set adequate values for this header according to their user interface language and even if a user can change it, this happens rarely (and is frowned upon as it leads to fingerprinting). + +This header is a hint to be used when the server has no way of determining the language via another way, like a specific URL, that is controlled by an explicit user decision. It is recommended that the server never overrides an explicit decision. The content of the Accept-Language is often out of the control of the user (like when traveling and using an Internet Cafe in a different country); the user may also want to visit a page in another language than the locale of their user interface. + +If the server cannot serve any matching language, it can theoretically send back a 406 (Not Acceptable) error code. But, for a better user experience, this is rarely done and more common way is to ignore the Accept-Language header in this case. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language`, + }, + { + Name: "Controls", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Controls", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Controls`, + }, + { + Name: "Expect", + Summary: "Indicates expectations that need to be fulfilled by the server to properly handle the request.", + Description: `The Expect HTTP request header indicates expectations that need to be fulfilled by the server in order to properly handle the request. + +The only expectation defined in the specification is Expect: 100-continue, to which the server shall respond with: + + 100 if the information contained in the header is sufficient to cause an immediate success, + 417 (Expectation Failed) if it cannot meet the expectation; or any other 4xx status otherwise. + +For example, the server may reject a request if its Content-Length is too large. + +No common browsers send the Expect header, but some other clients such as cURL do so by default. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect`, + }, + { + Name: "Max-Forwards", + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Controls", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Controls`, + }, + { + Name: "Cookies", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Cookies", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Cookies`, + }, + { + Name: "Cookie", + Summary: "Contains stored HTTP cookies previously sent by the server with the Set-Cookie header.", + Description: `The Cookie HTTP request header contains stored HTTP cookies previously sent by the server with the Set-Cookie header. + +The Cookie header is optional and may be omitted if, for example, the browser's privacy settings block cookies. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie`, + }, + { + Name: "Set-Cookie", + Summary: "Send cookies from the server to the user-agent.", + Description: `The Set-Cookie HTTP response header is used to send cookies from the server to the user agent, so the user agent can send them back to the server later. + +For more information, see the guide on HTTP cookies. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie`, + }, + { + Name: "CORS", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS", + Description: `Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell browsers to give a web application running at one origin, access to selected resources from a different origin. A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, or port) from its own. + +An example of a cross-origin request: the front-end JavaScript code served from https://domain-a.com uses XMLHttpRequest to make a request for https://domain-b.com/data.json. + +For security reasons, browsers restrict cross-origin HTTP requests initiated from scripts. For example, XMLHttpRequest and the Fetch API follow the same-origin policy. This means that a web application using those APIs can only request resources from the same origin the application was loaded from, unless the response from other origins includes the right CORS headers. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS`, + }, + { + Name: "Access-Control-Allow-Origin", + Summary: "Indicates whether the response can be shared.", + Description: `The Access-Control-Allow-Origin response header indicates whether the response can be shared with requesting code from the given origin. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin`, + }, + { + Name: "Access-Control-Allow-Credentials", + Summary: "Indicates whether the response to the request can be exposed when the credentials flag is true.", + Description: `The Access-Control-Allow-Credentials response header tells browsers whether to expose the response to frontend JavaScript code when the request's credentials mode (Request.credentials) is include. + +When a request's credentials mode (Request.credentials) is include, browsers will only expose the response to frontend JavaScript code if the Access-Control-Allow-Credentials value is true. + +Credentials are cookies, authorization headers or TLS client certificates. + +When used as part of a response to a preflight request, this indicates whether or not the actual request can be made using credentials. Note that simple GET requests are not preflighted, and so if a request is made for a resource with credentials, if this header is not returned with the resource, the response is ignored by the browser and not returned to web content. + +The Access-Control-Allow-Credentials header works in conjunction with the XMLHttpRequest.withCredentials property or with the credentials option in the Request() constructor of the Fetch API. For a CORS request with credentials, in order for browsers to expose the response to frontend JavaScript code, both the server (using the Access-Control-Allow-Credentials header) and the client (by setting the credentials mode for the XHR, Fetch, or Ajax request) must indicate that they’re opting in to including credentials. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials`, + }, + { + Name: "Access-Control-Allow-Headers", + Summary: "Used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.", + Description: `The Access-Control-Allow-Headers response header is used in response to a preflight request which includes the Access-Control-Request-Headers to indicate which HTTP headers can be used during the actual request. + +This header is required if the request has an Access-Control-Request-Headers header. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers`, + }, + { + Name: "Access-Control-Allow-Methods", + Summary: "Specifies the methods allowed when accessing the resource in response to a preflight request.", + Description: `The Access-Control-Allow-Methods response header specifies the method or methods allowed when accessing the resource in response to a preflight request. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods`, + }, + { + Name: "Access-Control-Expose-Headers", + Summary: "Indicates which headers can be exposed as part of the response by listing their names.", + Description: `The Access-Control-Expose-Headers response header indicates which headers can be exposed as part of the response by listing their names. + +By default, only the 6 CORS-safelisted response headers are exposed: + + Cache-Control + Content-Language + Content-Type + Expires + Last-Modified + Pragma + +If you want clients to be able to access other headers, you have to list them using the Access-Control-Expose-Headers header. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers`, + }, + { + Name: "Access-Control-Max-Age", + Summary: "Indicates how long the results of a preflight request can be cached.", + Description: `The Access-Control-Max-Age response header indicates how long the results of a preflight request (that is the information contained in the Access-Control-Allow-Methods and Access-Control-Allow-Headers headers) can be cached. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Max-Age`, + }, + { + Name: "Access-Control-Request-Headers", + Summary: "Used when issuing a preflight request to let the server know which HTTP headers will be used when the actual request is made.", + Description: `The Access-Control-Request-Headers request header is used by browsers when issuing a preflight request, to let the server know which HTTP headers the client might send when the actual request is made. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Headers`, + }, + { + Name: "Origin", + Summary: "Indicates where a fetch originates from.", + Description: `The Origin request header indicates where a fetch originates from. It doesn't include any path information, but only the server name. It is sent with CORS requests, as well as with POST requests. It is similar to the Referer header, but, unlike this header, it doesn't disclose the whole path. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin`, + }, + { + Name: "Timing-Allow-Origin", + Summary: "Specifies origins that are allowed to see values of attributes retrieved via features of the Resource Timing API, which would otherwise be reported as zero due to cross-origin restrictions.", + Description: `The Timing-Allow-Origin response header specifies origins that are allowed to see values of attributes retrieved via features of the Resource Timing API, which would otherwise be reported as zero due to cross-origin restrictions. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Timing-Allow-Origin`, + }, + { + Name: "Do Not Track", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Do_Not_Track", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Do_Not_Track`, + }, + { + Name: "DNT", + Summary: "Expresses the user's tracking preference.", + Description: `The DNT (Do Not Track) request header indicates the user's tracking preference. It lets users indicate whether they would prefer privacy rather than personalized content. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DNT`, + }, + { + Name: "Tk", + Summary: "Indicates the tracking status of the corresponding response.", + Description: `The Tk response header indicates the tracking status that applied to the corresponding request. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Tk`, + }, + { + Name: "Downloads", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Downloads", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Downloads`, + }, + { + Name: "Content-Disposition", + Summary: "Indicates if the resource transmitted should be displayed inline (default behavior without the header), or if it should be handled like a download and the browser should present a “Save As” dialog.", + Description: `In a regular HTTP response, the Content-Disposition response header is a header indicating if the content is expected to be displayed inline in the browser, that is, as a Web page or as part of a Web page, or as an attachment, that is downloaded and saved locally. + +In a multipart/form-data body, the HTTP Content-Disposition general header is a header that can be used on the subpart of a multipart body to give information about the field it applies to. The subpart is delimited by the boundary defined in the Content-Type header. Used on the body itself, Content-Disposition has no effect. + +The Content-Disposition header is defined in the larger context of MIME messages for e-mail, but only a subset of the possible parameters apply to HTTP forms and POST requests. Only the value form-data, as well as the optional directive name and filename, can be used in the HTTP context. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition`, + }, + { + Name: "Message body information", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Message_body_information", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Message_body_information`, + }, + { + Name: "Content-Length", + Summary: "The size of the resource, in decimal number of bytes.", + Description: `The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length`, + }, + { + Name: "Content-Type", + Summary: "Indicates the media type of the resource.", + Description: `The Content-Type entity header is used to indicate the media type of the resource. + +In responses, a Content-Type header tells the client what the content type of the returned content actually is. Browsers will do MIME sniffing in some cases and will not necessarily follow the value of this header; to prevent this behavior, the header X-Content-Type-Options can be set to nosniff. + +In requests, (such as POST or PUT), the client tells the server what type of data is actually sent. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type`, + }, + { + Name: "Content-Encoding", + Summary: "Used to specify the compression algorithm.", + Description: `The Content-Encoding entity header is used to compress the media-type. When present, its value indicates which encodings were applied to the entity-body. It lets the client know how to decode in order to obtain the media-type referenced by the Content-Type header. + +The recommendation is to compress data as much as possible and therefore to use this field, but some types of resources, such as jpeg images, are already compressed. Sometimes, using additional compression doesn't reduce payload size and can even make the payload longer. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding`, + }, + { + Name: "Content-Language", + Summary: "Describes the human language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.", + Description: `The Content-Language entity header is used to describe the language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language. + +For example, if "Content-Language: de-DE" is set, it says that the document is intended for German language speakers (however, it doesn't indicate the document is written in German. For example, it might be written in English as part of a language course for German speakers. If you want to indicate which language the document is written in, use the lang attribute instead). + +If no Content-Language is specified, the default is that the content is intended for all language audiences. Multiple language tags are also possible, as well as applying the Content-Language header to various media types and not only to textual documents. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Language`, + }, + { + Name: "Content-Location", + Summary: "Indicates an alternate location for the returned data.", + Description: `The Content-Location header indicates an alternate location for the returned data. The principal use is to indicate the URL of a resource transmitted as the result of content negotiation. + +Location and Content-Location are different. Location indicates the URL of a redirect, while Content-Location indicates the direct URL to use to access the resource, without further content negotiation in the future. Location is a header associated with the response, while Content-Location is associated with the data returned. This distinction may seem abstract without examples. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Location`, + }, + { + Name: "Proxies", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Proxies", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Proxies`, + }, + { + Name: "Forwarded", + Summary: "Contains information from the client-facing side of proxy servers that is altered or lost when a proxy is involved in the path of the request.", + Description: `The Forwarded header contains information from the client-facing side of proxy servers that is altered or lost when a proxy is involved in the path of the request. + +The alternative and de-facto standard versions of this header are the X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto headers. + +This header is used for debugging, statistics, and generating location-dependent content and by design it exposes privacy sensitive information, such as the IP address of the client. Therefore the user's privacy must be kept in mind when deploying this header. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded`, + }, + { + Name: "X-Forwarded-For", + Summary: "Identifies the originating IP addresses of a client connecting to a web server through an HTTP proxy or a load balancer.", + Description: `The X-Forwarded-For (XFF) header is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or a load balancer. When traffic is intercepted between clients and servers, server access logs contain the IP address of the proxy or load balancer only. To see the original IP address of the client, the X-Forwarded-For request header is used. + +This header is used for debugging, statistics, and generating location-dependent content and by design it exposes privacy sensitive information, such as the IP address of the client. Therefore the user's privacy must be kept in mind when deploying this header. + +A standardized version of this header is the HTTP Forwarded header. + +X-Forwarded-For is also an email-header indicating that an email-message was forwarded from another account. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For`, + }, + { + Name: "X-Forwarded-Host", + Summary: "Identifies the original host requested that a client used to connect to your proxy or load balancer.", + Description: `The X-Forwarded-Host (XFH) header is a de-facto standard header for identifying the original host requested by the client in the Host HTTP request header. + +Host names and ports of reverse proxies (load balancers, CDNs) may differ from the origin server handling the request, in that case the X-Forwarded-Host header is useful to determine which Host was originally used. + +This header is used for debugging, statistics, and generating location-dependent content and by design it exposes privacy sensitive information, such as the IP address of the client. Therefore the user's privacy must be kept in mind when deploying this header. + +A standardized version of this header is the HTTP Forwarded header. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host`, + }, + { + Name: "X-Forwarded-Proto", + Summary: "Identifies the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.", + Description: `The X-Forwarded-Proto (XFP) header is a de-facto standard header for identifying the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer. Your server access logs contain the protocol used between the server and the load balancer, but not the protocol used between the client and the load balancer. To determine the protocol used between the client and the load balancer, the X-Forwarded-Proto request header can be used. + +A standardized version of this header is the HTTP Forwarded header. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto`, + }, + { + Name: "Via", + Summary: "Added by proxies, both forward and reverse proxies, and can appear in the request headers and the response headers.", + Description: `The Via general header is added by proxies, both forward and reverse proxies, and can appear in the request headers and the response headers. It is used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders along the request/response chain. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Via`, + }, + { + Name: "Redirects", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Redirects", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Redirects`, + }, + { + Name: "Location", + Summary: "Indicates the URL to redirect a page to.", + Description: `The Location response header indicates the URL to redirect a page to. It only provides a meaning when served with a 3xx (redirection) or 201 (created) status response. + +In cases of redirection, the HTTP method used to make the new request to fetch the page pointed to by Location depends of the original method and of the kind of redirection: + + If 303 (See Also) responses always lead to the use of a GET method, 307 (Temporary Redirect) and 308 (Permanent Redirect) don't change the method used in the original request; + 301 (Permanent Redirect) and 302 (Found) doesn't change the method most of the time, though older user-agents may (so you basically don't know). + +All responses with one of these status codes send a Location header. + +In cases of resource creation, it indicates the URL to the newly created resource. + +Location and Content-Location are different: Location indicates the target of a redirection (or the URL of a newly created resource), while Content-Location indicates the direct URL to use to access the resource when content negotiation happened, without the need of further content negotiation. Location is a header associated with the response, while Content-Location is associated with the entity returned. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location`, + }, + { + Name: "Request context", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Request_context", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Request_context`, + }, + { + Name: "From", + Summary: "Contains an Internet email address for a human user who controls the requesting user agent.", + Description: `The From request header contains an Internet email address for a human user who controls the requesting user agent. + +If you are running a robotic user agent (e.g. a crawler), the From header should be sent, so you can be contacted if problems occur on servers, such as if the robot is sending excessive, unwanted, or invalid requests. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/From`, + }, + { + Name: "Host", + Summary: "Specifies the domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening.", + Description: `The Host request header specifies the domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening. + +If no port is given, the default port for the service requested (e.g., "80" for an HTTP URL) is implied. + +A Host header field must be sent in all HTTP/1.1 request messages. A 400 (Bad Request) status code will be sent to any HTTP/1.1 request message that lacks a Host header field or contains more than one. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host`, + }, + { + Name: "Referer", + Summary: "The address of the previous web page from which a link to the currently requested page was followed.", + Description: `The Referer request header contains the address of the previous web page from which a link to the currently requested page was followed. The Referer header allows servers to identify where people are visiting them from and may use that data for analytics, logging, or optimized caching, for example. + +Important: Although this header has many innocent uses it can have undesirable consequences for user security and privacy. See Referer header: privacy and security concerns for more information and mitigations. + +Note that referer is actually a misspelling of the word "referrer". See HTTP referer on Wikipedia for more details. + +A Referer header is not sent by browsers if: + + The referring resource is a local "file" or "data" URI. + An unsecured HTTP request is used and the referring page was received with a secure protocol (HTTPS). + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer`, + }, + { + Name: "Referrer", + Summary: "See the Referer header", + Description: `This header was spelt incorrectly in the original implementation. See Referer for further details. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer`, + }, + { + Name: "Referrer-Policy", + Summary: "Governs which referrer information sent in the Referer header should be included with requests made.", + Description: `The Referrer-Policy HTTP header controls how much referrer information (sent via the Referer header) should be included with requests. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy`, + }, + { + Name: "User-Agent", + Summary: "Contains a characteristic string that allows the network protocol peers to identify the application type, operating system, software vendor or software version of the requesting software user agent. See also the Firefox user agent string reference.", + Description: `The User-Agent request header is a characteristic string that lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting user agent. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent`, + }, + { + Name: "Response context", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Response_context", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Response_context`, + }, + { + Name: "Allow", + Summary: "Lists the set of HTTP request methods support by a resource.", + Description: `The Allow header lists the set of methods supported by a resource. + +This header must be sent if the server responds with a 405 Method Not Allowed status code to indicate which request methods can be used. An empty Allow header indicates that the resource allows no request methods, which might occur temporarily for a given resource, for example. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Allow`, + }, + { + Name: "Server", + Summary: "Contains information about the software used by the origin server to handle the request.", + Description: `The Server header contains information about the software used by the origin server to handle the request. + +Overly long and detailed Server values should be avoided as they potentially reveal internal implementation details that might make it (slightly) easier for attackers to find and exploit known security holes. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server`, + }, + { + Name: "Range requests", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Range_requests", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Range_requests`, + }, + { + Name: "Accept-Ranges", + Summary: "Indicates if the server supports range requests, and if so in which unit the range can be expressed.", + Description: `The Accept-Ranges response HTTP header is a marker used by the server to advertise its support of partial requests. The value of this field indicates the unit that can be used to define a range. + +In presence of an Accept-Ranges header, the browser may try to resume an interrupted download, rather than to start it from the start again. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Ranges`, + }, + { + Name: "Range", + Summary: "Indicates the part of a document that the server should return.", + Description: `The Range HTTP request header indicates the part of a document that the server should return. Several parts can be requested with one Range header at once, and the server may send back these ranges in a multipart document. If the server sends back ranges, it uses the 206 Partial Content for the response. If the ranges are invalid, the server returns the 416 Range Not Satisfiable error. The server can also ignore the Range header and return the whole document with a 200 status code. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range`, + }, + { + Name: "If-Range", + Summary: "Creates a conditional range request that is only fulfilled if the given etag or date matches the remote resource. Used to prevent downloading two ranges from incompatible version of the resource.", + Description: `The If-Range HTTP request header makes a range request conditional: if the condition is fulfilled, the range request will be issued and the server sends back a 206 Partial Content answer with the appropriate body. If the condition is not fulfilled, the full resource is sent back, with a 200 OK status. + +This header can be used either with a Last-Modified validator, or with an ETag, but not with both. + +The most common use case is to resume a download, to guarantee that the stored resource has not been modified since the last fragment has been received. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Range`, + }, + { + Name: "Content-Range", + Summary: "Indicates where in a full body message a partial message belongs.", + Description: `The Content-Range response HTTP header indicates where in a full body message a partial message belongs. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range`, + }, + { + Name: "Security", + IsTitle: true, + Summary: "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Security", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Security`, + }, + { + Name: "Cross-Origin-Embedder-Policy (COEP)", + Summary: "Allows a server to declare an embedder policy for a given document.", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Security`, + }, + { + Name: "Cross-Origin-Opener-Policy (COOP)", + Summary: "Prevents other domains from opening/controlling a window.", + Description: `https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Security`, + }, + { + Name: "Cross-Origin-Resource-Policy (CORP)", + Summary: "Prevents other domains from reading the response of the resources to which this header is applied.", + Description: `The HTTP Cross-Origin-Resource-Policy response header conveys a desire that the browser blocks no-cors cross-origin/cross-site requests to the given resource. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy`, + }, + { + Name: "Content-Security-Policy (CSP)", + Summary: "Controls resources the user agent is allowed to load for a given page.", + Description: `The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (XSS). + +For more information, see the introductory article on Content Security Policy (CSP). + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy`, + }, + { + Name: "Content-Security-Policy-Report-Only", + Summary: "Allows web developers to experiment with policies by monitoring, but not enforcing, their effects. These violation reports consist of JSON documents sent via an HTTP POST request to the specified URI.", + Description: `The HTTP Content-Security-Policy-Report-Only response header allows web developers to experiment with policies by monitoring (but not enforcing) their effects. These violation reports consist of JSON documents sent via an HTTP POST request to the specified URI. + +For more information, see also this article on Content Security Policy (CSP). + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only`, + }, + { + Name: "Expect-CT", + Summary: "Allows sites to opt in to reporting and/or enforcement of Certificate Transparency requirements, which prevents the use of misissued certificates for that site from going unnoticed. When a site enables the Expect-CT header, they are requesting that Chrome check that any certificate for that site appears in public CT logs.", + Description: `The Expect-CT header allows sites to opt in to reporting and/or enforcement of Certificate Transparency requirements, which prevents the use of misissued certificates for that site from going unnoticed. + +CT requirements can be satisfied by servers via any one of the following mechanisms: + + X.509v3 certificate extension to allow embedding of signed certificate timestamps issued by individual logs + A TLS extension of type signed_certificate_timestamp sent during the handshake + Supporting OCSP stapling (that is, the status_request TLS extension) and providing a SignedCertificateTimestampList + +When a site enables the Expect-CT header, they are requesting that the browser check that any certificate for that site appears in public CT logs. + +Browsers ignore the Expect-CT header when sent over HTTP, the header only has effect on HTTPS connections. + +https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT`, + }, + { + Name: "Feature-Policy", + Summary: "Provides a mechanism to allow and deny the use of browser features in its own frame, and in iframes that it embeds.", + Description: `The HTTP Feature-Policy header provides a mechanism to allow and deny the use of browser features in its own frame, and in content within any