remove retired locales (#699)

6 files changed, 0 insertions, 1549 deletions

diff --git a/files/th/web/http/cors/errors/index.html b/files/th/web/http/cors/errors/index.html
deleted file mode 100644
index d1dd12dc75..0000000000
--- a/files/th/web/http/cors/errors/index.html
+++ /dev/null
@@ -1,76 +0,0 @@
----
-title: CORS errors
-slug: Web/HTTP/CORS/Errors
-tags:
-  - CORS
-  - Errors
-  - HTTP
-  - HTTPS
-  - Messages
-  - NeedsTranslation
-  - Same-origin
-  - Security
-  - TopicStub
-  - console
-  - troubleshooting
-translation_of: Web/HTTP/CORS/Errors
----
-<div>{{HTTPSidebar}}</div>
-
-<p><span class="seoSummary"><a href="/en-US/docs/Web/HTTP/CORS">Cross-Origin Resource Sharing</a> ({{Glossary("CORS")}}) is a standard that allows a server to relax the <a href="/en-US/docs/Web/Security/Same-origin_policy">same-origin policy</a>. This is used to explicitly allow some cross-origin requests while rejecting others.</span> For example, if a site offers an embeddable service, it may be necessary to relax certain restrictions. Setting up such a CORS configuration isn't necessarily easy and may present some challenges. In these pages, we'll look into some common CORS error messages and how to resolve them.</p>
-
-<p>If the CORS configuration isn't setup correctly, the browser console will present an error like <code>"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite"</code> indicating that the request was blocked due to violating the CORS security rules. This might not necessarily be a set-up mistake, though. It's possible that the request is in fact intentionally being disallowed by the user's web application and remote external service. However, If the endpoint is meant to be available, some debugging is needed to succeed.</p>
-
-<h2 id="Identifying_the_issue">Identifying the issue</h2>
-
-<p>To understand the underlying issue with the CORS configuration, you need to find out which request is at fault and why. These steps may help you do so:</p>
-
-<ol>
- <li>Navigate to the web site or web app in question and open the <a href="/en-US/docs/Tools">Developer Tools</a>.</li>
- <li>Now try to reproduce the failing transaction and check the <a href="/en-US/docs/Tools/Web_Console">console</a> if you are seeing a CORS violation error message. It will probably look like this:</li>
-</ol>
-
-<p><img alt="Firefox console showing CORS error" src="https://mdn.mozillademos.org/files/16050/cors-error2.png"></p>
-
-<p>The text of the error message will be something similar to the following:</p>
-
-<pre>Cross<span class="message-body-wrapper"><span class="message-flex-body"><span class="devtools-monospace message-body">-Origin Request Blocked: The Same Origin Policy disallows
-reading the remote resource at <em>https://some-url-here</em>. (<em>Reason:
-additional information here</em>).</span></span></span></pre>
-
-<div class="note">
-<p><span class="message-body-wrapper"><span class="message-flex-body"><span class="devtools-monospace message-body"><strong>Note:</strong> For security reasons, specifics about what went wrong with a CORS request <em>are not available to JavaScript code</em>. All the code knows is that an error occurred. The only way to determine what specifically went wrong is to look at the browser's console for details.</span></span></span></p>
-</div>
-
-<h2 id="CORS_error_messages">CORS error messages</h2>
-
-<p>Firefox's console displays messages in its console when requests fail due to CORS. Part of the error text is a "reason" message that provides added insight into what went wrong.  The reason messages are listed below; click the message to open an article explaining the error in more detail and offering possible solutions.</p>
-
-<ul>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSDisabled">Reason: CORS disabled</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed">Reason: CORS request did not succeed</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSOriginHeaderNotAdded">Reason: CORS header ‘Origin’ cannot be added</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSExternalRedirectNotAllowed">Reason: CORS request external redirect not allowed</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp">Reason: CORS request not http</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowOrigin">Reason: CORS header ‘Access-Control-Allow-Origin’ missing</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin">Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘xyz’</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials">Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMethodNotFound">Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowCredentials">Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed">Reason: CORS preflight channel did not succeed</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowMethod">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowHeader">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight">Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel</a></li>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMultipleAllowOriginNotAllowed">Reason: Multiple CORS header ‘Access-Control-Allow-Origin’ not allowed</a></li>
-</ul>
-
-<h2 id="See_also">See also</h2>
-
-<ul>
- <li>Glossary: {{Glossary("CORS")}}</li>
- <li><a href="/en-US/docs/Web/HTTP/CORS">CORS introduction</a></li>
- <li><a href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">Server-side CORS settings</a></li>
- <li><a href="/en-US/docs/Web/HTML/CORS_enabled_image">CORS enabled image</a></li>
- <li><a href="/en-US/docs/Web/HTML/CORS_settings_attributes">CORS settings attributes</a></li>
- <li><a href="https://www.test-cors.org">https://www.test-cors.org</a> – page to test CORS requests</li>
-</ul>
diff --git a/files/th/web/http/cors/index.html b/files/th/web/http/cors/index.html
deleted file mode 100644
index 195504e50f..0000000000
--- a/files/th/web/http/cors/index.html
+++ /dev/null
@@ -1,565 +0,0 @@
----
-title: Cross-Origin Resource Sharing (CORS)
-slug: Web/HTTP/CORS
-tags:
-  - AJAX
-  - CORS
-  - Cross-Origin Resource Sharing
-  - Fetch
-  - Fetch API
-  - HTTP
-  - HTTP Access Controls
-  - NeedsTranslation
-  - Same-origin policy
-  - Security
-  - TopicStub
-  - XMLHttpRequest
-  - 'l10n:priority'
-translation_of: Web/HTTP/CORS
----
-<p><span class="seoSummary">Cross-Origin Resource Sharing ({{Glossary("CORS")}}) is a mechanism that uses additional {{Glossary("HTTP")}} headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin.</span> A web application makes a <strong>cross-origin HTTP request</strong> when it requests a resource that has a different origin (domain, protocol, and port) than its own origin.</p>
-
-<p>An example of a cross-origin request: The frontend JavaScript code for a web application served from <code>http://domain-a.com</code> uses {{domxref("XMLHttpRequest")}} to make a request for <code>http://api.domain-b.com/data.json</code>.</p>
-
-<p>For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, <code>XMLHttpRequest</code> and the <a href="/en-US/docs/Web/API/Fetch_API">Fetch API</a> follow the <a href="/en-US/docs/Web/Security/Same-origin_policy">same-origin policy</a>. This means that a web application using those APIs can only request HTTP resources from the same origin the application was loaded from, unless the response from the other origin includes the right CORS headers.</p>
-
-<p><img alt="" src="https://mdn.mozillademos.org/files/14295/CORS_principle.png" style="height: 305px; width: 440px;"></p>
-
-<p>The CORS mechanism supports secure cross-origin requests and data transfers between browsers and web servers. Modern browsers use CORS in an API container such as <code>XMLHttpRequest</code> or <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> to help mitigate the risks of cross-origin HTTP requests.</p>
-
-<h2 id="Who_should_read_this_article">Who should read this article?</h2>
-
-<p>Everyone, really.</p>
-
-<p>More specifically, this article is for web administrators, server developers, and front-end developers. Modern browsers handle the client-side components of cross-origin sharing, including headers and policy enforcement. But this new standard means servers have to handle new request and response headers. Another article for server developers discussing <a href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">cross-origin sharing from a server perspective (with PHP code snippets)</a> is supplementary reading.</p>
-
-<h2 id="What_requests_use_CORS">What requests use CORS?</h2>
-
-<p>This <a class="external" href="https://fetch.spec.whatwg.org/#http-cors-protocol">cross-origin sharing standard</a> is used to enable cross-site HTTP requests for:</p>
-
-<ul>
- <li>Invocations of the {{domxref("XMLHttpRequest")}} or <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> APIs in a cross-site manner, as discussed above.</li>
- <li>Web Fonts (for cross-domain font usage in <code>@font-face</code> within CSS), <a class="external" href="https://www.w3.org/TR/css-fonts-3/#font-fetching-requirements">so that servers can deploy TrueType fonts that can only be cross-site loaded and used by web sites that are permitted to do so.</a></li>
- <li><a href="/en-US/docs/Web/API/WebGL_API/Tutorial/Using_textures_in_WebGL">WebGL textures</a>.</li>
- <li>Images/video frames drawn to a canvas using {{domxref("CanvasRenderingContext2D.drawImage()", "drawImage()")}}.</li>
-</ul>
-
-<p>This article is a general discussion of Cross-Origin Resource Sharing and includes a discussion of the necessary HTTP headers.</p>
-
-<h2 id="Functional_overview">Functional overview</h2>
-
-<p>The Cross-Origin Resource Sharing standard works by adding new <a href="/en-US/docs/Web/HTTP/Headers">HTTP headers</a> that allow servers to describe the set of origins that are permitted to read that information using a web browser. Additionally, for HTTP request methods that can cause side-effects on server's data (in particular, for HTTP methods other than {{HTTPMethod("GET")}}, or for {{HTTPMethod("POST")}} usage with certain <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME types</a>), the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP {{HTTPMethod("OPTIONS")}} request method, and then, upon "approval" from the server, sending the actual request with the actual HTTP request method. Servers can also notify clients whether "credentials" (including <a href="/en-US/docs/Web/HTTP/Cookies">Cookies</a> and HTTP Authentication data) should be sent with requests.</p>
-
-<p>CORS failures result in errors, but for security reasons, specifics about what went wrong <em>are not available to JavaScript code</em>. All the code knows is that an error occurred. The only way to determine what specifically went wrong is to look at the browser's console for details.</p>
-
-<p>Subsequent sections discuss scenarios, as well as provide a breakdown of the HTTP headers used.</p>
-
-<h2 id="Examples_of_access_control_scenarios">Examples of access control scenarios</h2>
-
-<p>Here, we present three scenarios that illustrate how Cross-Origin Resource Sharing works. All of these examples use the {{domxref("XMLHttpRequest")}} object, which can be used to make cross-site invocations in any supporting browser.</p>
-
-<p>The JavaScript snippets included in these sections (and running instances of the server-code that correctly handles these cross-site requests) can be found "in action" at <a class="external" href="http://arunranga.com/examples/access-control/">http://arunranga.com/examples/access-control/</a>, and will work in browsers that support cross-site <code>XMLHttpRequest</code>.</p>
-
-<p>A discussion of Cross-Origin Resource Sharing from a server perspective (including PHP code snippets) can be found in the <a class="internal" href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">Server-Side Access Control (CORS)</a> article.</p>
-
-<h3 id="Simple_requests">Simple requests</h3>
-
-<p>Some requests don’t trigger a <a href="#Preflighted_requests">CORS preflight</a>. Those are called “simple requests” in this article, though the {{SpecName('Fetch')}} spec (which defines CORS) doesn’t use that term. A request that doesn’t trigger a <a href="#Preflighted_requests">CORS preflight</a>—a so-called “simple request”—is one that meets all the following conditions:</p>
-
-<ul>
- <li>The only allowed methods are:
-  <ul>
-   <li>{{HTTPMethod("GET")}}</li>
-   <li>{{HTTPMethod("HEAD")}}</li>
-   <li>{{HTTPMethod("POST")}}</li>
-  </ul>
- </li>
- <li>Apart from the headers set automatically by the user agent (for example, {{HTTPHeader("Connection")}}, {{HTTPHeader("User-Agent")}}, or <a href="https://fetch.spec.whatwg.org/#forbidden-header-name">any of the other headers with names defined in the Fetch spec as a “forbidden header name”</a>), the only headers which are allowed to be manually set are <a href="https://fetch.spec.whatwg.org/#cors-safelisted-request-header">those which the Fetch spec defines as being a “CORS-safelisted request-header”</a>, which are:
-  <ul>
-   <li>{{HTTPHeader("Accept")}}</li>
-   <li>{{HTTPHeader("Accept-Language")}}</li>
-   <li>{{HTTPHeader("Content-Language")}}</li>
-   <li>{{HTTPHeader("Content-Type")}} (but note the additional requirements below)</li>
-   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#dpr">DPR</a></code></li>
-   <li>{{HTTPHeader("Downlink")}}</li>
-   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#save-data">Save-Data</a></code></li>
-   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#viewport-width">Viewport-Width</a></code></li>
-   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#width">Width</a></code></li>
-  </ul>
- </li>
- <li>The only allowed values for the {{HTTPHeader("Content-Type")}} header are:
-  <ul>
-   <li><code>application/x-www-form-urlencoded</code></li>
-   <li><code>multipart/form-data</code></li>
-   <li><code>text/plain</code></li>
-  </ul>
- </li>
- <li>No event listeners are registered on any {{domxref("XMLHttpRequestUpload")}} object used in the request; these are accessed using the {{domxref("XMLHttpRequest.upload")}} property.</li>
- <li>No {{domxref("ReadableStream")}} object is used in the request.</li>
-</ul>
-
-<div class="note"><strong>Note:</strong> These are the same kinds of cross-site requests that web content can already issue, and no response data is released to the requester unless the server sends an appropriate header. Therefore, sites that prevent cross-site request forgery have nothing new to fear from HTTP access control.</div>
-
-<div class="note"><strong>Note:</strong> WebKit Nightly and Safari Technology Preview place additional restrictions on the values allowed in the {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, and {{HTTPHeader("Content-Language")}} headers. If any of those headers have ”non-standard” values, WebKit/Safari does not consider the request to meet the conditions for a “simple request”. What WebKit/Safari considers “non-standard” values for those headers is not documented except in the following WebKit bugs: <a href="https://bugs.webkit.org/show_bug.cgi?id=165178" rel="nofollow noreferrer">Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language</a>, <a href="https://bugs.webkit.org/show_bug.cgi?id=165566" rel="nofollow noreferrer">Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS</a>, and <a href="https://bugs.webkit.org/show_bug.cgi?id=166363" rel="nofollow noreferrer">Switch to a blacklist model for restricted Accept headers in simple CORS requests</a>. No other browsers implement those extra restrictions, because they’re not part of the spec.</div>
-
-<p>For example, suppose web content on domain <code class="plain">http://foo.example</code> wishes to invoke content on domain <code class="plain">http://bar.other</code>. Code of this sort might be used within JavaScript deployed on foo.example:</p>
-
-<pre class="brush: js" id="line1">var invocation = new XMLHttpRequest();
-var url = 'http://bar.other/resources/public-data/';
-
-function callOtherDomain() {
-  if(invocation) {
-    invocation.open('GET', url, true);
-    invocation.onreadystatechange = handler;
-    invocation.send();
-  }
-}
-</pre>
-
-<p>This will lead to a simple exchange between the client and the server, using CORS headers to handle the privileges:</p>
-
-<p><img alt="" src="https://mdn.mozillademos.org/files/14293/simple_req.png" style="height: 224px; width: 521px;"></p>
-
-<p>Let us look at what the browser will send to the server in this case, and let's see how the server responds:</p>
-
-<pre class="brush: shell;highlight:[10,16]">GET /resources/public-data/ HTTP/1.1
-Host: bar.other
-User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
-Origin: http://foo.example
-
-
-HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 00:23:53 GMT
-Server: Apache/2.0.61
-Access-Control-Allow-Origin: *
-Keep-Alive: timeout=2, max=100
-Connection: Keep-Alive
-Transfer-Encoding: chunked
-Content-Type: application/xml
-
-[XML Data]
-</pre>
-
-<p>Lines 1 - 10 are headers sent. The main HTTP request header of note here is the {{HTTPHeader("Origin")}} header on line 10 above, which shows that the invocation is coming from content on the domain <code class="plain">http://foo.example</code>.</p>
-
-<p>Lines 13 - 22 show the HTTP response from the server on domain <code class="plain">http://bar.other</code>. In response, the server sends back an {{HTTPHeader("Access-Control-Allow-Origin")}} header, shown above in line 16. The use of the {{HTTPHeader("Origin")}} header and of {{HTTPHeader("Access-Control-Allow-Origin")}} show the access control protocol in its simplest use. In this case, the server responds with a <code>Access-Control-Allow-Origin: *</code> which means that the resource can be accessed by <strong>any</strong> domain in a cross-site manner. If the resource owners at <code class="plain">http://bar.other</code> wished to restrict access to the resource to requests only from <code class="plain">http://foo.example</code>, they would send back:</p>
-
-<p><code class="plain">Access-Control-Allow-Origin: http://foo.example</code></p>
-
-<p>Note that now, no domain other than <code class="plain">http://foo.example</code> (identified by the ORIGIN: header in the request, as in line 10 above) can access the resource in a cross-site manner. The <code>Access-Control-Allow-Origin</code> header should contain the value that was sent in the request's <code>Origin</code> header.</p>
-
-<h3 id="Preflighted_requests">Preflighted requests</h3>
-
-<p>Unlike <a href="#Simple_requests">“simple requests” (discussed above)</a>, "preflighted" requests first send an HTTP request by the {{HTTPMethod("OPTIONS")}} method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data.</p>
-
-<p>In particular, a request is preflighted if <strong>any of the following conditions</strong> is true:</p>
-
-<ul>
- <li><strong>If</strong> the request uses any of the following methods:
-
-  <ul>
-   <li>{{HTTPMethod("PUT")}}</li>
-   <li>{{HTTPMethod("DELETE")}}</li>
-   <li>{{HTTPMethod("CONNECT")}}</li>
-   <li>{{HTTPMethod("OPTIONS")}}</li>
-   <li>{{HTTPMethod("TRACE")}}</li>
-   <li>{{HTTPMethod("PATCH")}}</li>
-  </ul>
- </li>
- <li><strong>Or if</strong>, apart from the headers set automatically by the user agent (for example, {{HTTPHeader("Connection")}}, {{HTTPHeader("User-Agent")}}, or <a href="https://fetch.spec.whatwg.org/#forbidden-header-name">any of the other header with a name defined in the Fetch spec as a “forbidden header name”</a>), the request includes any headers other than <a href="https://fetch.spec.whatwg.org/#cors-safelisted-request-header">those which the Fetch spec defines as being a “CORS-safelisted request-header”</a>, which are the following:
-  <ul>
-   <li>{{HTTPHeader("Accept")}}</li>
-   <li>{{HTTPHeader("Accept-Language")}}</li>
-   <li>{{HTTPHeader("Content-Language")}}</li>
-   <li>{{HTTPHeader("Content-Type")}} (but note the additional requirements below)</li>
-   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#dpr">DPR</a></code></li>
-   <li>{{HTTPHeader("Downlink")}}</li>
-   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#save-data">Save-Data</a></code></li>
-   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#viewport-width">Viewport-Width</a></code></li>
-   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#width">Width</a></code></li>
-  </ul>
- </li>
- <li><strong>Or if</strong> the {{HTTPHeader("Content-Type")}} header has a value other than the following:
-  <ul>
-   <li><code>application/x-www-form-urlencoded</code></li>
-   <li><code>multipart/form-data</code></li>
-   <li><code>text/plain</code></li>
-  </ul>
- </li>
- <li><strong>Or if</strong> one or more event listeners are registered on an {{domxref("XMLHttpRequestUpload")}} object used in the request.</li>
- <li><strong>Or if</strong> a {{domxref("ReadableStream")}} object is used in the request.</li>
-</ul>
-
-<div class="note"><strong>Note:</strong> WebKit Nightly and Safari Technology Preview place additional restrictions on the values allowed in the {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, and {{HTTPHeader("Content-Language")}} headers. If any of those headers have ”non-standard” values, WebKit/Safari preflights the request. What WebKit/Safari considers “non-standard” values for those headers is not documented except in the following WebKit bugs: <a href="https://bugs.webkit.org/show_bug.cgi?id=165178" rel="nofollow noreferrer">Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language</a>, <a href="https://bugs.webkit.org/show_bug.cgi?id=165566" rel="nofollow noreferrer">Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS</a>, and <a href="https://bugs.webkit.org/show_bug.cgi?id=166363" rel="nofollow noreferrer">Switch to a blacklist model for restricted Accept headers in simple CORS requests</a>. No other browsers implement those extra restrictions, because they’re not part of the spec.</div>
-
-<p>The following is an example of a request that will be preflighted.</p>
-
-<pre class="brush: js" id="line1">var invocation = new XMLHttpRequest();
-var url = 'http://bar.other/resources/post-here/';
-var body = '&lt;?xml version="1.0"?&gt;&lt;person&gt;&lt;name&gt;Arun&lt;/name&gt;&lt;/person&gt;';
-
-function callOtherDomain(){
-  if(invocation)
-    {
-      invocation.open('POST', url, true);
-      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
-      invocation.setRequestHeader('Content-Type', 'application/xml');
-      invocation.onreadystatechange = handler;
-      invocation.send(body);
-    }
-}
-
-......
-</pre>
-
-<p>In the example above, line 3 creates an XML body to send with the <code>POST</code> request in line 8. Also, on line 9, a "customized" (non-standard) HTTP request header is set (<code>X-PINGOTHER: pingpong</code>). Such headers are not part of the HTTP/1.1 protocol, but are generally useful to web applications. Since the request uses a Content-Type of <code>application/xml</code>, and since a custom header is set, this request is preflighted.</p>
-
-<p><img alt="" src="https://mdn.mozillademos.org/files/14289/prelight.png"></p>
-
-<p>(Note: as described below, the actual POST request does not include the Access-Control-Request-* headers; they are needed only for the OPTIONS request.)</p>
-
-<p>Let's take a look at the full exchange between client and server. The first exchange is the <em>preflight request/response</em>:</p>
-
-<pre class="brush: none;highlight:[1,10,11,17-20]">OPTIONS /resources/post-here/ HTTP/1.1
-Host: bar.other
-User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-Origin: http://foo.example
-Access-Control-Request-Method: POST
-Access-Control-Request-Headers: X-PINGOTHER, Content-Type
-
-
-HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 01:15:39 GMT
-Server: Apache/2.0.61 (Unix)
-Access-Control-Allow-Origin: http://foo.example
-Access-Control-Allow-Methods: POST, GET, OPTIONS
-Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
-Access-Control-Max-Age: 86400
-Vary: Accept-Encoding, Origin
-Content-Encoding: gzip
-Content-Length: 0
-Keep-Alive: timeout=2, max=100
-Connection: Keep-Alive
-Content-Type: text/plain
-</pre>
-
-<p>Once the preflight request is complete, the real request is sent:</p>
-
-<pre class="brush: none;">POST /resources/post-here/ HTTP/1.1
-Host: bar.other
-User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-X-PINGOTHER: pingpong
-Content-Type: text/xml; charset=UTF-8
-Referer: http://foo.example/examples/preflightInvocation.html
-Content-Length: 55
-Origin: http://foo.example
-Pragma: no-cache
-Cache-Control: no-cache
-
-&lt;?xml version="1.0"?&gt;&lt;person&gt;&lt;name&gt;Arun&lt;/name&gt;&lt;/person&gt;
-
-
-HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 01:15:40 GMT
-Server: Apache/2.0.61 (Unix)
-Access-Control-Allow-Origin: http://foo.example
-Vary: Accept-Encoding, Origin
-Content-Encoding: gzip
-Content-Length: 235
-Keep-Alive: timeout=2, max=99
-Connection: Keep-Alive
-Content-Type: text/plain
-
-[Some GZIP'd payload]
-</pre>
-
-<p>Lines 1 - 12 above represent the preflight request with the {{HTTPMethod("OPTIONS")}} method. The browser determines that it needs to send this based on the request parameters that the JavaScript code snippet above was using, so that the server can respond whether it is acceptable to send the request with the actual request parameters. OPTIONS is an HTTP/1.1 method that is used to determine further information from servers, and is a {{Glossary("safe")}} method, meaning that it can't be used to change the resource. Note that along with the OPTIONS request, two other request headers are sent (lines 10 and 11 respectively):</p>
-
-<pre class="brush: none">Access-Control-Request-Method: POST
-Access-Control-Request-Headers: X-PINGOTHER, Content-Type
-</pre>
-
-<p>The {{HTTPHeader("Access-Control-Request-Method")}} header notifies the server as part of a preflight request that when the actual request is sent, it will be sent with a <code>POST</code> request method. The {{HTTPHeader("Access-Control-Request-Headers")}} header notifies the server that when the actual request is sent, it will be sent with a <code>X-PINGOTHER</code> and Content-Type custom headers. The server now has an opportunity to determine whether it wishes to accept a request under these circumstances.</p>
-
-<p>Lines 14 - 26 above are the response that the server sends back indicating that the request method (<code>POST</code>) and request headers (<code>X-PINGOTHER</code>) are acceptable. In particular, let's look at lines 17-20:</p>
-
-<pre class="brush: none">Access-Control-Allow-Origin: http://foo.example
-Access-Control-Allow-Methods: POST, GET
-Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
-Access-Control-Max-Age: 86400</pre>
-
-<p>The server responds with <code>Access-Control-Allow-Methods</code> and says that <code>POST</code> and <code>GET</code> are viable methods to query the resource in question. Note that this header is similar to the {{HTTPHeader("Allow")}} response header, but used strictly within the context of access control.</p>
-
-<p>The server also sends <code>Access-Control-Allow-Headers</code> with a value of "<code>X-PINGOTHER, Content-Type</code>", confirming that these are permitted headers to be used with the actual request. Like <code>Access-Control-Allow-Methods</code>, <code>Access-Control-Allow-Headers</code> is a comma separated list of acceptable headers.</p>
-
-<p>Finally, {{HTTPHeader("Access-Control-Max-Age")}} gives the value in seconds for how long the response to the preflight request can be cached for without sending another preflight request. In this case, 86400 seconds is 24 hours. Note that each browser has a <a href="/en-US/docs/Web/HTTP/Headers/Access-Control-Max-Age">maximum internal value</a> that takes precedence when the <code>Access-Control-Max-Age</code> is greater.</p>
-
-<h4 id="Preflighted_requests_and_redirects">Preflighted requests and redirects</h4>
-
-<p>Not all browsers currently support following redirects after a preflighted request. If a redirect occurs after a preflighted request, some browsers currently will report an error message such as the following.</p>
-
-<blockquote>
-<p>The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight</p>
-</blockquote>
-
-<blockquote>
-<p>Request requires preflight, which is disallowed to follow cross-origin redirect</p>
-</blockquote>
-
-<p>The CORS protocol originally required that behavior but <a href="https://github.com/whatwg/fetch/commit/0d9a4db8bc02251cc9e391543bb3c1322fb882f2">was subsequently changed to no longer require it</a>. However, not all browsers have implemented the change, and so still exhibit the behavior that was originally required.</p>
-
-<p>So until all browsers catch up with the spec, you may be able to work around this limitation by doing one or both of the following:</p>
-
-<ul>
- <li>change the server-side behavior to avoid the preflight and/or to avoid the redirect—if you have control over the server the request is being made to</li>
- <li>change the request such that it is a <a href="#Simple_requests">simple request</a> that doesn’t cause a preflight</li>
-</ul>
-
-<p>But if it’s not possible to make those changes, then another way that may be possible is to this:</p>
-
-<ol>
- <li>Make a <a href="#Simple_requests">simple request</a> (using {{domxref("Response.url")}} for the Fetch API, or {{domxref("XMLHttpRequest.responseURL")}}) to determine what URL the real preflighted request would end up at.</li>
- <li>Make another request (the “real” request) using the URL you obtained from <code>Response.url</code> or <code>XMLHttpRequest.responseURL</code> in the first step.</li>
-</ol>
-
-<p>However, if the request is one that triggers a preflight due to the presence of the <code>Authorization</code> header in the request, you won’t be able to work around the limitation using the steps above. And you won’t be able to work around it at all unless you have control over the server the request is being made to.</p>
-
-<h3 id="Requests_with_credentials">Requests with credentials</h3>
-
-<p>The most interesting capability exposed by both {{domxref("XMLHttpRequest")}} or <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> and CORS is the ability to make "credentialed" requests that are aware of <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a> and HTTP Authentication information. By default, in cross-site <code>XMLHttpRequest"</code> or <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> invocations, browsers will <strong>not</strong> send credentials. A specific flag has to be set on the <code>XMLHttpRequest"</code> object or the {{domxref("Request")}} constructor when it is invoked.</p>
-
-<p>In this example, content originally loaded from <code class="plain">http://foo.example</code> makes a simple GET request to a resource on <code class="plain">http://bar.other</code> which sets Cookies. Content on foo.example might contain JavaScript like this:</p>
-
-<pre class="brush: js" id="line1">var invocation = new XMLHttpRequest();
-var url = 'http://bar.other/resources/credentialed-content/';
-
-function callOtherDomain(){
-  if(invocation) {
-    invocation.open('GET', url, true);
-    invocation.withCredentials = true;
-    invocation.onreadystatechange = handler;
-    invocation.send();
-  }
-}</pre>
-
-<p>Line 7 shows the flag on {{domxref("XMLHttpRequest")}} that has to be set in order to make the invocation with Cookies, namely the <code>withCredentials</code> boolean value. By default, the invocation is made without Cookies. Since this is a simple <code>GET</code> request, it is not preflighted, but the browser will <strong>reject</strong> any response that does not have the {{HTTPHeader("Access-Control-Allow-Credentials")}}<code>: true</code> header, and <strong>not</strong> make the response available to the invoking web content.</p>
-
-<p><img alt="" src="https://mdn.mozillademos.org/files/14291/cred-req.png" style="height: 223px; width: 521px;"></p>
-
-<p>Here is a sample exchange between client and server:</p>
-
-<pre class="brush: none">GET /resources/access-control-with-credentials/ HTTP/1.1
-Host: bar.other
-User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-Referer: http://foo.example/examples/credential.html
-Origin: http://foo.example
-Cookie: pageAccess=2
-
-
-HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 01:34:52 GMT
-Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
-X-Powered-By: PHP/5.2.6
-Access-Control-Allow-Origin: http://foo.example
-Access-Control-Allow-Credentials: true
-Cache-Control: no-cache
-Pragma: no-cache
-Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
-Vary: Accept-Encoding, Origin
-Content-Encoding: gzip
-Content-Length: 106
-Keep-Alive: timeout=2, max=100
-Connection: Keep-Alive
-Content-Type: text/plain
-
-
-[text/plain payload]
-</pre>
-
-<p>Although line 11 contains the Cookie destined for the content on <code class="plain">http://bar.other</code>, if bar.other did not respond with an {{HTTPHeader("Access-Control-Allow-Credentials")}}<code>: true</code> (line 19) the response would be ignored and not made available to web content.</p>
-
-<h4 id="Credentialed_requests_and_wildcards">Credentialed requests and wildcards</h4>
-
-<p>When responding to a credentialed request, the server <strong>must</strong> specify an origin in the value of the <code>Access-Control-Allow-Origin</code> header, instead of specifying the "<code>*</code>" wildcard.</p>
-
-<p>Because the request headers in the above example include a <code>Cookie</code> header, the request would fail if the value of the <code>Access-Control-Allow-Origin</code> header were "*". But it does not fail: Because the value of the <code>Access-Control-Allow-Origin</code> header is "<code class="plain">http://foo.example</code>" (an actual origin) rather than the "<code>*</code>" wildcard, the credential-cognizant content is returned to the invoking web content.</p>
-
-<p>Note that the <code>Set-Cookie</code> response header in the example above also sets a further cookie. In case of failure, an exception—depending on the API used—is raised.</p>
-
-<h4 id="Third-party_cookies">Third-party cookies</h4>
-
-<p>Note that cookies set in CORS responses are subject to normal third-party cookie policies. In the example above, the page is loaded from <code>foo.example</code>, but the cookie on line 22 is sent by <code>bar.other</code>, and would thus not be saved if the user has configured their browser to reject all third-party cookies.</p>
-
-<h2 id="The_HTTP_response_headers">The HTTP response headers</h2>
-
-<p>This section lists the HTTP response headers that servers send back for access control requests as defined by the Cross-Origin Resource Sharing specification. The previous section gives an overview of these in action.</p>
-
-<h3 id="Access-Control-Allow-Origin">Access-Control-Allow-Origin</h3>
-
-<p>A returned resource may have one {{HTTPHeader("Access-Control-Allow-Origin")}} header, with the following syntax:</p>
-
-<pre class="brush: none">Access-Control-Allow-Origin: &lt;origin&gt; | *
-</pre>
-
-<p><code>Access-Control-Allow-Origin</code> specifies either a single origin, which tells browsers to allow that origin to access the resource; or else — for requests <strong>without</strong> credentials — the "<code>*</code>" wildcard, to tell browsers to allow any origin to access the resource.</p>
-
-<p>For example, to allow code from the origin <code>http://mozilla.org</code> to access the resource, you can specify:</p>
-
-<pre class="brush: none">Access-Control-Allow-Origin: http://mozilla.org</pre>
-
-<p>If the server specifies a single origin rather than the "<code>*</code>" wildcard, then the server should also include <code>Origin</code> in the {{HTTPHeader("Vary")}} response header — to indicate to clients that server responses will differ based on the value of the {{HTTPHeader("Origin")}} request header.</p>
-
-<h3 id="Access-Control-Expose-Headers">Access-Control-Expose-Headers</h3>
-
-<p>The {{HTTPHeader("Access-Control-Expose-Headers")}} header lets a server whitelist headers that browsers are allowed to access. For example:</p>
-
-<pre class="brush: none">Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
-</pre>
-
-<p>This allows the <code>X-My-Custom-Header</code> and <code>X-Another-Custom-Header</code> headers to be exposed to the browser.</p>
-
-<h3 id="Access-Control-Max-Age">Access-Control-Max-Age</h3>
-
-<p>The {{HTTPHeader("Access-Control-Max-Age")}} header indicates how long the results of a preflight request can be cached. For an example of a preflight request, see the above examples.</p>
-
-<pre class="brush: none">Access-Control-Max-Age: &lt;delta-seconds&gt;
-</pre>
-
-<p>The <code>delta-seconds</code> parameter indicates the number of seconds the results can be cached.</p>
-
-<h3 id="Access-Control-Allow-Credentials">Access-Control-Allow-Credentials</h3>
-
-<p>The {{HTTPHeader("Access-Control-Allow-Credentials")}} header Indicates whether or not the response to the request can be exposed when the <code>credentials</code> flag is true. 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 <code>GET</code> 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.</p>
-
-<pre class="brush: none">Access-Control-Allow-Credentials: true
-</pre>
-
-<p><a class="internal" href="#Requests_with_credentials">Credentialed requests</a> are discussed above.</p>
-
-<h3 id="Access-Control-Allow-Methods">Access-Control-Allow-Methods</h3>
-
-<p>The {{HTTPHeader("Access-Control-Allow-Methods")}} header specifies the method or methods allowed when accessing the resource. This is used in response to a preflight request. The conditions under which a request is preflighted are discussed above.</p>
-
-<pre class="brush: none">Access-Control-Allow-Methods: &lt;method&gt;[, &lt;method&gt;]*
-</pre>
-
-<p>An example of a <a class="internal" href="#Preflighted_requests">preflight request is given above</a>, including an example which sends this header to the browser.</p>
-
-<h3 id="Access-Control-Allow-Headers">Access-Control-Allow-Headers</h3>
-
-<p>The {{HTTPHeader("Access-Control-Allow-Headers")}} header is used in response to a <a class="internal" href="#Preflighted_requests">preflight request</a> to indicate which HTTP headers can be used when making the actual request.</p>
-
-<pre class="brush: none">Access-Control-Allow-Headers: &lt;field-name&gt;[, &lt;field-name&gt;]*
-</pre>
-
-<h2 id="The_HTTP_request_headers">The HTTP request headers</h2>
-
-<p>This section lists headers that clients may use when issuing HTTP requests in order to make use of the cross-origin sharing feature. Note that these headers are set for you when making invocations to servers. Developers using cross-site {{domxref("XMLHttpRequest")}} capability do not have to set any cross-origin sharing request headers programmatically.</p>
-
-<h3 id="Origin">Origin</h3>
-
-<p>The {{HTTPHeader("Origin")}} header indicates the origin of the cross-site access request or preflight request.</p>
-
-<pre class="brush: none">Origin: &lt;origin&gt;
-</pre>
-
-<p>The origin is a URI indicating the server from which the request initiated. It does not include any path information, but only the server name.</p>
-
-<div class="note"><strong>Note:</strong> The <code>origin</code> can be the empty string; this is useful, for example, if the source is a <code>data</code> URL.</div>
-
-<p>Note that in any access control request, the {{HTTPHeader("Origin")}} header is <strong>always</strong> sent.</p>
-
-<h3 id="Access-Control-Request-Method">Access-Control-Request-Method</h3>
-
-<p>The {{HTTPHeader("Access-Control-Request-Method")}} is used when issuing a preflight request to let the server know what HTTP method will be used when the actual request is made.</p>
-
-<pre class="brush: none">Access-Control-Request-Method: &lt;method&gt;
-</pre>
-
-<p>Examples of this usage can be <a class="internal" href="#Preflighted_requests">found above.</a></p>
-
-<h3 id="Access-Control-Request-Headers">Access-Control-Request-Headers</h3>
-
-<p>The {{HTTPHeader("Access-Control-Request-Headers")}} header is used when issuing a preflight request to let the server know what HTTP headers will be used when the actual request is made.</p>
-
-<pre class="brush: none">Access-Control-Request-Headers: &lt;field-name&gt;[, &lt;field-name&gt;]*
-</pre>
-
-<p>Examples of this usage can be <a class="internal" href="#Preflighted_requests">found above</a>.</p>
-
-<h2 id="Specifications">Specifications</h2>
-
-<table class="standard-table">
- <tbody>
-  <tr>
-   <th scope="col">Specification</th>
-   <th scope="col">Status</th>
-   <th scope="col">Comment</th>
-  </tr>
-  <tr>
-   <td>{{SpecName('Fetch', '#cors-protocol', 'CORS')}}</td>
-   <td>{{Spec2('Fetch')}}</td>
-   <td>New definition; supplants <a href="https://www.w3.org/TR/cors/">W3C CORS</a> specification.</td>
-  </tr>
- </tbody>
-</table>
-
-<h2 id="Browser_compatibility">Browser compatibility</h2>
-
-<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
-
-<p>{{Compat("http.headers.Access-Control-Allow-Origin")}}</p>
-
-<h3 id="Compatibility_notes">Compatibility notes</h3>
-
-<ul>
- <li>Internet Explorer 8 and 9 expose CORS via the <code>XDomainRequest</code> object, but have a full implementation in IE 10.</li>
- <li>While Firefox 3.5 introduced support for cross-site <code>XMLHttpRequests</code> and Web Fonts, certain requests were limited until later versions. Specifically, Firefox 7 introduced the ability for cross-site HTTP requests for WebGL Textures, and Firefox 9 added support for Images drawn on a canvas using <code>drawImage()</code>.</li>
-</ul>
-
-<h2 id="See_also">See also</h2>
-
-<ul>
- <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">CORS errors</a></li>
- <li><a href="https://enable-cors.org/server.html">Enable CORS: I want to add CORS support to my server</a></li>
- <li>{{domxref("XMLHttpRequest")}}</li>
- <li><a href="/en-US/docs/Web/API/Fetch_API">Fetch API</a></li>
- <li><a class="external" href="http://www.kendoui.com/blogs/teamblog/posts/11-10-03/using_cors_with_all_modern_browsers.aspx">Using CORS with All (Modern) Browsers</a></li>
- <li><a href="http://www.html5rocks.com/en/tutorials/cors/">Using CORS - HTML5 Rocks</a>
-  <ul>
-  </ul>
- </li>
- <li><a class="external" href="https://arunranga.com/examples/access-control/">Code Samples Showing <code>XMLHttpRequest</code> and Cross-Origin Resource Sharing</a></li>
- <li><a href="https://github.com/jackblackevo/cors-jsonp-sample">Client-Side &amp; Server-Side (Java) sample for Cross-Origin Resource Sharing (CORS)</a></li>
- <li><a class="internal" href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">Cross-Origin Resource Sharing From a Server-Side Perspective (PHP, etc.)</a></li>
- <li><a href="https://stackoverflow.com/questions/43871637/no-access-control-allow-origin-header-is-present-on-the-requested-resource-whe/43881141#43881141">Stack Overflow answer with “how to” info for dealing with common problems</a>:
-  <ul>
-   <li>How to avoid the CORS preflight</li>
-   <li>How to use a CORS proxy to get around <em>“No Access-Control-Allow-Origin header”</em></li>
-   <li>How to fix <em>“Access-Control-Allow-Origin header must not be the wildcard”</em></li>
-  </ul>
- </li>
-</ul>
-
-<div>{{HTTPSidebar}}</div>
diff --git a/files/th/web/http/headers/index.html b/files/th/web/http/headers/index.html
deleted file mode 100644
index 11d0d9ca86..0000000000
--- a/files/th/web/http/headers/index.html
+++ /dev/null
@@ -1,469 +0,0 @@
----
-title: HTTP headers
-slug: Web/HTTP/Headers
-tags:
-  - HTTP
-  - HTTP Header
-  - Headers
-  - NeedsTranslation
-  - Networking
-  - Overview
-  - Reference
-  - TopicStub
-translation_of: Web/HTTP/Headers
----
-<div>{{HTTPSidebar}}</div>
-
-<p><span class="seoSummary"><strong>HTTP headers</strong> 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 (<code>:</code>), then by its value.</span> {{Glossary("Whitespace")}} before the value is ignored.</p>
-
-<p>Custom proprietary headers have historically been used with an <code>X-</code> prefix, but this convention was deprecated in June 2012 because of the inconveniences it caused when nonstandard fields became standard in <a href="https://tools.ietf.org/html/rfc6648">RFC 6648</a>; others are listed in an <a class="external" href="http://www.iana.org/assignments/message-headers/perm-headers.html">IANA registry</a>, whose original content was defined in <a class="external" href="http://tools.ietf.org/html/rfc4229">RFC 4229</a>. IANA also maintains a <a class="external" href="http://www.iana.org/assignments/message-headers/prov-headers.html">registry of proposed new HTTP headers</a>.</p>
-
-<p>Headers can be grouped according to their contexts:</p>
-
-<ul>
- <li>{{Glossary("General header", "General headers")}} apply to both requests and responses, but with no relation to the data transmitted in the body.</li>
- <li>{{Glossary("Request header", "Request headers")}} contain more information about the resource to be fetched, or about the client requesting the resource.</li>
- <li>{{Glossary("Response header", "Response headers")}} hold additional information about the response, like its location or about the server providing it.</li>
- <li>{{Glossary("Entity header", "Entity headers")}} contain information about the body of the resource, like its <a href="/en-US/docs/Web/HTTP/Headers/Content-Length">content length</a> or <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME type</a>.</li>
-</ul>
-
-<p>Headers can also be grouped according to how {{Glossary("Proxy_server", "proxies")}} handle them:</p>
-
-<ul>
- <li>{{ httpheader("Connection") }}</li>
- <li>{{ httpheader("Keep-Alive") }}</li>
- <li>{{ httpheader("Proxy-Authenticate") }}</li>
- <li>{{ httpheader("Proxy-Authorization") }}</li>
- <li>{{ httpheader("TE") }}</li>
- <li>{{ httpheader("Trailer") }}</li>
- <li>{{ httpheader("Transfer-Encoding") }}</li>
- <li>{{ httpheader("Upgrade") }} (see also <a href="/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism">Protocol upgrade mechanism</a>).</li>
-</ul>
-
-<dl>
- <dt id="e2e">End-to-end headers</dt>
- <dd>These headers <em>must</em> 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.</dd>
- <dt id="hbh">Hop-by-hop headers</dt>
- <dd>These headers are meaningful only for a single transport-level connection, and <em>must not</em> be retransmitted by proxies or cached. Note that only hop-by-hop headers may be set using the {{httpheader("Connection")}} general header.</dd>
-</dl>
-
-<h2 id="Authentication">Authentication</h2>
-
-<dl>
- <dt>{{HTTPHeader("WWW-Authenticate")}}</dt>
- <dd>Defines the authentication method that should be used to access a resource.</dd>
- <dt>{{HTTPHeader("Authorization")}}</dt>
- <dd>Contains the credentials to authenticate a user-agent with a server.</dd>
- <dt>{{HTTPHeader("Proxy-Authenticate")}}</dt>
- <dd>Defines the authentication method that should be used to access a resource behind a proxy server.</dd>
- <dt>{{HTTPHeader("Proxy-Authorization")}}</dt>
- <dd>Contains the credentials to authenticate a user agent with a proxy server.</dd>
-</dl>
-
-<h2 id="Caching">Caching</h2>
-
-<dl>
- <dt>{{HTTPHeader("Age")}}</dt>
- <dd>The time, in seconds, that the object has been in a proxy cache.</dd>
- <dt>{{HTTPHeader("Cache-Control")}}</dt>
- <dd>Directives for caching mechanisms in both requests and responses.</dd>
- <dt>{{HTTPHeader("Clear-Site-Data")}}</dt>
- <dd>Clears browsing data (e.g. cookies, storage, cache) associated with the requesting website.</dd>
- <dt>{{HTTPHeader("Expires")}}</dt>
- <dd>The date/time after which the response is considered stale.</dd>
- <dt>{{HTTPHeader("Pragma")}}</dt>
- <dd>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 <code>Cache-Control</code> header is not yet present.</dd>
- <dt>{{HTTPHeader("Warning")}}</dt>
- <dd>General warning information about possible problems.</dd>
-</dl>
-
-<h2 id="Client_hints">Client hints</h2>
-
-<p>HTTP {{Glossary("Client_hints", "Client hints")}} are a work in progress. Actual documentation can be found on the <a href="https://httpwg.org/http-extensions/client-hints.html">website of the HTTP working group</a>.</p>
-
-<dl>
- <dt>{{HTTPHeader("Accept-CH")}} {{experimental_inline}}</dt>
- <dd>Servers can advertise support for Client Hints using the <code>Accept-CH</code> header field or an equivalent HTML <code>&lt;meta&gt;</code> element with <code>http-equiv</code> attribute (<a href="https://httpwg.org/http-extensions/client-hints.html#HTML5"><cite>[HTML5]</cite></a>).</dd>
- <dt>{{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}}</dt>
- <dd>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 (<a href="https://httpwg.org/http-extensions/client-hints.html#RFC6454"><cite>[RFC6454]</cite></a>).</dd>
- <dt>{{HTTPHeader("Early-Data")}} {{experimental_inline}}</dt>
- <dd>Indicates that the request has been conveyed in early data.</dd>
- <dt>{{HTTPHeader("Content-DPR")}} {{experimental_inline}}</dt>
- <dd>A number that indicates the ratio between physical pixels over CSS pixels of the selected image response.</dd>
- <dt>{{HTTPHeader("DPR")}} {{experimental_inline}}</dt>
- <dd>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 <a href="https://httpwg.org/http-extensions/client-hints.html#CSSVAL"><cite>[CSSVAL]</cite></a>) of the layout viewport (Section 9.1.1 of <a href="https://httpwg.org/http-extensions/client-hints.html#CSS2"><cite>[CSS2]</cite></a>) on the device.</dd>
- <dt>{{HTTPHeader("Device-Memory")}} {{experimental_inline}}</dt>
- <dd>Technically a part of Device Memory API, this header represents an approximate amount of RAM client has.</dd>
- <dt>{{HTTPHeader("Save-Data")}} {{experimental_inline}}</dt>
- <dd>A boolean that indicates the user agent's preference for reduced data usage.</dd>
- <dt>{{HTTPHeader("Viewport-Width")}} {{experimental_inline}}</dt>
- <dd>
- <div id="rfc.section.3.3.p.1">
- <p>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).</p>
- </div>
-
- <div id="rfc.section.3.3.p.2">
- <p>If <code>Viewport-Width</code> occurs in a message more than once, the last value overrides all previous occurrences.</p>
- </div>
- </dd>
- <dt>{{HTTPHeader("Width")}} {{experimental_inline}}</dt>
- <dd>
- <div id="rfc.section.3.2.p.1">
- <p>The <code>Width</code> 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).</p>
- </div>
-
- <div id="rfc.section.3.2.p.2">
- <p>If the desired resource width is not known at the time of the request or the resource does not have a display width, the <code>Width</code> header field can be omitted. If <code>Width</code> occurs in a message more than once, the last value overrides all previous occurrences</p>
- </div>
- </dd>
-</dl>
-
-<h2 id="Conditionals">Conditionals</h2>
-
-<dl>
- <dt>{{HTTPHeader("Last-Modified")}}</dt>
- <dd>The last modification date of the resource, used to compare several versions of the same resource. It is less accurate than {{HTTPHeader("ETag")}}, but easier to calculate in some environments. Conditional requests using {{HTTPHeader("If-Modified-Since")}} and {{HTTPHeader("If-Unmodified-Since")}} use this value to change the behavior of the request.</dd>
- <dt>{{HTTPHeader("ETag")}}</dt>
- <dd>A unique string identifying the version of the resource. Conditional requests using {{HTTPHeader("If-Match")}} and {{HTTPHeader("If-None-Match")}} use this value to change the behavior of the request.</dd>
- <dt>{{HTTPHeader("If-Match")}}</dt>
- <dd>Makes the request conditional, and applies the method only if the stored resource matches one of the given ETags.</dd>
- <dt>{{HTTPHeader("If-None-Match")}}</dt>
- <dd>Makes the request conditional, and applies the method only if the stored resource <em>doesn't</em> 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.</dd>
- <dt>{{HTTPHeader("If-Modified-Since")}}</dt>
- <dd>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.</dd>
- <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt>
- <dd>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.</dd>
- <dt>{{HTTPHeader("Vary")}}</dt>
- <dd>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.</dd>
-</dl>
-
-<h2 id="Connection_management">Connection management</h2>
-
-<dl>
- <dt>{{HTTPHeader("Connection")}}</dt>
- <dd>Controls whether the network connection stays open after the current transaction finishes.</dd>
- <dt>{{HTTPHeader("Keep-Alive")}}</dt>
- <dd>Controls how long a persistent connection should stay open.</dd>
-</dl>
-
-<h2 id="Content_negotiation"><a href="/en-US/docs/Web/HTTP/Content_negotiation">Content negotiation</a></h2>
-
-<dl>
- <dt>{{HTTPHeader("Accept")}}</dt>
- <dd>Informs the server about the {{Glossary("MIME_type", "types")}} of data that can be sent back.</dd>
- <dt>{{HTTPHeader("Accept-Charset")}}</dt>
- <dd>Which {{Glossary("character encodings")}} the client understands.</dd>
- <dt>{{HTTPHeader("Accept-Encoding")}}</dt>
- <dd>The encoding algorithm, usually a <a href="/en-US/docs/Web/HTTP/Compression">compression algorithm</a>, that can be used on the resource sent back.</dd>
- <dt>{{HTTPHeader("Accept-Language")}}</dt>
- <dd>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).</dd>
-</dl>
-
-<h2 id="Controls">Controls</h2>
-
-<dl>
- <dt>{{HTTPHeader("Expect")}}</dt>
- <dd>Indicates expectations that need to be fulfilled by the server to properly handle the request.</dd>
- <dt>{{HTTPHeader("Max-Forwards")}}</dt>
-</dl>
-
-<h2 id="Cookies">Cookies</h2>
-
-<dl>
- <dt>{{HTTPHeader("Cookie")}}</dt>
- <dd>Contains stored <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a> previously sent by the server with the {{HTTPHeader("Set-Cookie")}} header.</dd>
- <dt>{{HTTPHeader("Set-Cookie")}}</dt>
- <dd>Send cookies from the server to the user-agent.</dd>
- <dt>{{HTTPHeader("Cookie2")}} {{obsolete_inline}}</dt>
- <dd>Contains an HTTP cookie previously sent by the server with the {{HTTPHeader("Set-Cookie2")}} header, but has been <strong>obsoleted</strong>. Use {{HTTPHeader("Cookie")}} instead.</dd>
- <dt>{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}</dt>
- <dd>Sends cookies from the server to the user-agent, but has been <strong>obsoleted</strong>. Use {{HTTPHeader("Set-Cookie")}} instead.</dd>
-</dl>
-
-<h2 id="CORS">CORS</h2>
-
-<p><em>Learn more about CORS <a href="CORS">here</a>.</em></p>
-
-<dl>
- <dt>{{HTTPHeader("Access-Control-Allow-Origin")}}</dt>
- <dd>Indicates whether the response can be shared.</dd>
- <dt>{{HTTPHeader("Access-Control-Allow-Credentials")}}</dt>
- <dd>Indicates whether the response to the request can be exposed when the credentials flag is true.</dd>
- <dt>{{HTTPHeader("Access-Control-Allow-Headers")}}</dt>
- <dd>Used in response to a {{Glossary("Preflight_request", "preflight request")}} to indicate which HTTP headers can be used when making the actual request.</dd>
- <dt>{{HTTPHeader("Access-Control-Allow-Methods")}}</dt>
- <dd>Specifies the methods allowed when accessing the resource in response to a preflight request.</dd>
- <dt>{{HTTPHeader("Access-Control-Expose-Headers")}}</dt>
- <dd>Indicates which headers can be exposed as part of the response by listing their names.</dd>
- <dt>{{HTTPHeader("Access-Control-Max-Age")}}</dt>
- <dd>Indicates how long the results of a preflight request can be cached.</dd>
- <dt>{{HTTPHeader("Access-Control-Request-Headers")}}</dt>
- <dd>Used when issuing a preflight request to let the server know which HTTP headers will be used when the actual request is made.</dd>
- <dt>{{HTTPHeader("Access-Control-Request-Method")}}</dt>
- <dd>Used when issuing a preflight request to let the server know which <a href="/en-US/docs/Web/HTTP/Methods">HTTP method</a> will be used when the actual request is made.</dd>
- <dt>{{HTTPHeader("Origin")}}</dt>
- <dd>Indicates where a fetch originates from.</dd>
- <dt>{{HTTPHeader("Timing-Allow-Origin")}}</dt>
- <dd>Specifies origins that are allowed to see values of attributes retrieved via features of the <a href="/en-US/docs/Web/API/Resource_Timing_API">Resource Timing API</a>, which would otherwise be reported as zero due to cross-origin restrictions.</dd>
-</dl>
-
-<h2 id="Do_Not_Track">Do Not Track</h2>
-
-<dl>
- <dt>{{HTTPHeader("DNT")}}</dt>
- <dd>Expresses the user's tracking preference.</dd>
- <dt>{{HTTPHeader("Tk")}}</dt>
- <dd>Indicates the tracking status of the corresponding response.</dd>
-</dl>
-
-<h2 id="Downloads">Downloads</h2>
-
-<dl>
- <dt>{{HTTPHeader("Content-Disposition")}}</dt>
- <dd>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.</dd>
-</dl>
-
-<h2 id="Message_body_information">Message body information</h2>
-
-<dl>
- <dt>{{HTTPHeader("Content-Length")}}</dt>
- <dd>The size of the resource, in decimal number of bytes.</dd>
- <dt>{{HTTPHeader("Content-Type")}}</dt>
- <dd>Indicates the media type of the resource.</dd>
- <dt>{{HTTPHeader("Content-Encoding")}}</dt>
- <dd>Used to specify the compression algorithm.</dd>
- <dt>{{HTTPHeader("Content-Language")}}</dt>
- <dd>Describes the human language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.</dd>
- <dt>{{HTTPHeader("Content-Location")}}</dt>
- <dd>Indicates an alternate location for the returned data.</dd>
-</dl>
-
-<h2 id="Proxies">Proxies</h2>
-
-<dl>
- <dt>{{HTTPHeader("Forwarded")}}</dt>
- <dd>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.</dd>
- <dt>{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}</dt>
- <dd>Identifies the originating IP addresses of a client connecting to a web server through an HTTP proxy or a load balancer.</dd>
- <dt>{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}</dt>
- <dd>Identifies the original host requested that a client used to connect to your proxy or load balancer.</dd>
- <dt>{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}</dt>
- <dd>Identifies the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.</dd>
- <dt>{{HTTPHeader("Via")}}</dt>
- <dd>Added by proxies, both forward and reverse proxies, and can appear in the request headers and the response headers.</dd>
-</dl>
-
-<h2 id="Redirects">Redirects</h2>
-
-<dl>
- <dt>{{HTTPHeader("Location")}}</dt>
- <dd>Indicates the URL to redirect a page to.</dd>
-</dl>
-
-<h2 id="Request_context">Request context</h2>
-
-<dl>
- <dt>{{HTTPHeader("From")}}</dt>
- <dd>Contains an Internet email address for a human user who controls the requesting user agent.</dd>
- <dt>{{HTTPHeader("Host")}}</dt>
- <dd>Specifies the domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening.</dd>
- <dt>{{HTTPHeader("Referer")}}</dt>
- <dd>The address of the previous web page from which a link to the currently requested page was followed.</dd>
- <dt>{{HTTPHeader("Referrer-Policy")}}</dt>
- <dd>Governs which referrer information sent in the {{HTTPHeader("Referer")}} header should be included with requests made.</dd>
- <dt>{{HTTPHeader("User-Agent")}}</dt>
- <dd>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 <a href="/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox">Firefox user agent string reference</a>.</dd>
-</dl>
-
-<h2 id="Response_context">Response context</h2>
-
-<dl>
- <dt>{{HTTPHeader("Allow")}}</dt>
- <dd>Lists the set of HTTP request methods supported by a resource.</dd>
- <dt>{{HTTPHeader("Server")}}</dt>
- <dd>Contains information about the software used by the origin server to handle the request.</dd>
-</dl>
-
-<h2 id="Range_requests">Range requests</h2>
-
-<dl>
- <dt>{{HTTPHeader("Accept-Ranges")}}</dt>
- <dd>Indicates if the server supports range requests, and if so in which unit the range can be expressed.</dd>
- <dt>{{HTTPHeader("Range")}}</dt>
- <dd>Indicates the part of a document that the server should return.</dd>
- <dt>{{HTTPHeader("If-Range")}}</dt>
- <dd>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.</dd>
- <dt>{{HTTPHeader("Content-Range")}}</dt>
- <dd>Indicates where in a full body message a partial message belongs.</dd>
-</dl>
-
-<h2 id="Security">Security</h2>
-
-<dl>
- <dt>{{HTTPHeader("Cross-Origin-Embedder-Policy")}} ({{Glossary("COEP")}})</dt>
- <dd>Allows a server to declare an embedder policy for a given document.</dd>
-</dl>
-
-<dl>
- <dt>{{HTTPHeader("Cross-Origin-Opener-Policy")}} ({{Glossary("COOP")}})</dt>
- <dd>Prevents other domains from opening/controlling a window.</dd>
-</dl>
-
-<dl>
- <dt>{{HTTPHeader("Cross-Origin-Resource-Policy")}} ({{Glossary("CORP")}})</dt>
- <dd>Prevents other domains from reading the response of the resources to which this header is applied.</dd>
- <dt>{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})</dt>
- <dd>Controls resources the user agent is allowed to load for a given page.</dd>
- <dt>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</dt>
- <dd>Allows web developers to experiment with policies by monitoring, but not enforcing, their effects. These violation reports consist of {{Glossary("JSON")}} documents sent via an HTTP <code>POST</code> request to the specified URI.</dd>
- <dt>{{HTTPHeader("Expect-CT")}}</dt>
- <dd>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.</dd>
- <dt>{{HTTPHeader("Feature-Policy")}}</dt>
- <dd>Provides a mechanism to allow and deny the use of browser features in its own frame, and in iframes that it embeds.</dd>
-</dl>
-
-<dl>
- <dt>{{HTTPHeader("Origin-Isolation")}} {{experimental_inline}}</dt>
- <dd>Provides a mechanism to allow web applications to isolate their origins.</dd>
-</dl>
-
-<dl>
- <dt>{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})</dt>
- <dd>Force communication using HTTPS instead of HTTP.</dd>
- <dt>{{HTTPHeader("Upgrade-Insecure-Requests")}}</dt>
- <dd>Sends a signal to the server expressing the client’s preference for an encrypted and authenticated response, and that it can successfully handle the {{CSP("upgrade-insecure-requests")}} directive.</dd>
- <dt>{{HTTPHeader("X-Content-Type-Options")}}</dt>
- <dd>Disables MIME sniffing and forces browser to use the type given in {{HTTPHeader("Content-Type")}}.</dd>
- <dt>{{HTTPHeader("X-Download-Options")}}</dt>
- <dd>The <code><a href="https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/jj542450(v=vs.85)?#the-noopen-directive">X-Download-Options</a></code> HTTP header indicates that the browser (Internet Explorer) should not display the option to "Open" a file that has been downloaded from an application, to prevent phishing attacks as the file otherwise would gain access to execute in the context of the application. (Note: related <a href="https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/18488178/">MS Edge bug</a>).</dd>
- <dt>{{HTTPHeader("X-Frame-Options")}} (XFO)</dt>
- <dd>Indicates whether a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} or {{HTMLElement("object")}}.</dd>
- <dt>{{HTTPHeader("X-Permitted-Cross-Domain-Policies")}}</dt>
- <dd>Specifies if a cross-domain policy file (<code>crossdomain.xml</code>) is allowed. The file may define a policy to grant clients, such as Adobe's Flash Player (now obsolete), Adobe Acrobat, Microsoft Silverlight (now obsolete), or Apache Flex, permission to handle data across domains that would otherwise be restricted due to the <a href="/en-US/docs/Web/Security/Same-origin_policy">Same-Origin Policy</a>. See the <a href="https://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html">Cross-domain Policy File Specification</a> for more information.</dd>
- <dt>{{HTTPHeader("X-Powered-By")}}</dt>
- <dd>May be set by hosting environments or other frameworks and contains information about them while not providing any usefulness to the application or its visitors. Unset this header to avoid exposing potential vulnerabilities.</dd>
- <dt>{{HTTPHeader("X-XSS-Protection")}}</dt>
- <dd>Enables cross-site scripting filtering.</dd>
-</dl>
-
-<h3 id="HTTP_Public_Key_Pinning_GlossaryHPKP">HTTP Public Key Pinning ({{Glossary("HPKP")}})</h3>
-
-<p>HTTP Public Key Pinning has been deprecated and removed in favor of Certificate Transparency and {{HTTPHeader("Expect-CT")}}.</p>
-
-<dl>
- <dt>{{HTTPHeader("Public-Key-Pins")}}</dt>
- <dd>Associates a specific cryptographic public key with a certain web server to decrease the risk of {{Glossary("MITM")}} attacks with forged certificates.</dd>
- <dt>{{HTTPHeader("Public-Key-Pins-Report-Only")}}</dt>
- <dd>Sends reports to the report-uri specified in the header and does still allow clients to connect to the server even if the pinning is violated.</dd>
-</dl>
-
-<h3 id="Fetch_metadata_request_headers">Fetch metadata request headers</h3>
-
-<dl>
- <dt>{{HTTPHeader("Sec-Fetch-Site")}}</dt>
- <dd>It is a request header that indicates the relationship between a request initiator's origin and its target's origin. It is a Structured Header whose value is a token with possible values <code>cross-site</code>, <code>same-origin</code>, <code>same-site</code>, and <code>none</code>.</dd>
- <dt>{{HTTPHeader("Sec-Fetch-Mode")}}</dt>
- <dd>It is a request header that indicates the request's mode to a server. It is a Structured Header whose value is a token with possible values <code>cors</code>, <code>navigate</code>, <code>nested-navigate</code>, <code>no-cors</code>, <code>same-origin</code>, and <code>websocket</code>.</dd>
- <dt>{{HTTPHeader("Sec-Fetch-User")}}</dt>
- <dd>It is a request header that indicates whether or not a navigation request was triggered by user activation. It is a Structured Header whose value is a boolean so possible values are <code>?0</code> for false and <code>?1</code> for true.</dd>
- <dt>{{HTTPHeader("Sec-Fetch-Dest")}}</dt>
- <dd>It is a request header that indicates the request's destination to a server. It is a Structured Header whose value is a token with possible values <code>audio</code>, <code>audioworklet</code>, <code>document</code>, <code>embed</code>, <code>empty</code>, <code>font</code>, <code>image</code>, <code>manifest</code>, <code>object</code>, <code>paintworklet</code>, <code>report</code>, <code>script</code>, <code>serviceworker</code>, <code>sharedworker</code>, <code>style</code>, <code>track</code>, <code>video</code>, <code>worker</code>, <code>xslt</code>, and <code>nested-document</code>.</dd>
-</dl>
-
-<h2 id="Server-sent_events">Server-sent events</h2>
-
-<dl>
- <dt>{{HTTPHeader("Last-Event-ID")}}</dt>
- <dd>...</dd>
- <dt>{{HTTPHeader("NEL")}} {{experimental_inline}}</dt>
- <dd>Defines a mechanism that enables developers to declare a network error reporting policy.</dd>
- <dt>{{HTTPHeader("Ping-From")}}</dt>
- <dd>...</dd>
- <dt>{{HTTPHeader("Ping-To")}}</dt>
- <dd>...</dd>
- <dt>{{HTTPHeader("Report-To")}}</dt>
- <dd>Used to specify a server endpoint for the browser to send warning and error reports to.</dd>
-</dl>
-
-<h2 id="Transfer_coding">Transfer coding</h2>
-
-<dl>
- <dt>{{HTTPHeader("Transfer-Encoding")}}</dt>
- <dd>Specifies the form of encoding used to safely transfer the entity to the user.</dd>
- <dt>{{HTTPHeader("TE")}}</dt>
- <dd>Specifies the transfer encodings the user agent is willing to accept.</dd>
- <dt>{{HTTPHeader("Trailer")}}</dt>
- <dd>Allows the sender to include additional fields at the end of chunked message.</dd>
-</dl>
-
-<h2 id="WebSockets">WebSockets</h2>
-
-<dl>
- <dt>{{HTTPHeader("Sec-WebSocket-Key")}}</dt>
- <dd>...</dd>
- <dt>{{HTTPHeader("Sec-WebSocket-Extensions")}}</dt>
- <dd>...</dd>
- <dt>{{HTTPHeader("Sec-WebSocket-Accept")}}</dt>
- <dd>...</dd>
- <dt>{{HTTPHeader("Sec-WebSocket-Protocol")}}</dt>
- <dd>...</dd>
- <dt>{{HTTPHeader("Sec-WebSocket-Version")}}</dt>
- <dd>...</dd>
-</dl>
-
-<h2 id="Other">Other</h2>
-
-<dl>
- <dt>{{HTTPHeader("Accept-Push-Policy")}} {{experimental_inline}}</dt>
- <dd>A client can express the desired push policy for a request by sending an <code><a href="https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00#section-3.1">Accept-Push-Policy</a></code> header field in the request.</dd>
- <dt>{{HTTPHeader("Accept-Signature")}} {{experimental_inline}}</dt>
- <dd>A client can send the <code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.7">Accept-Signature</a></code> header field to indicate intention to take advantage of any available signatures and to indicate what kinds of signatures it supports.</dd>
- <dt>{{HTTPHeader("Alt-Svc")}}</dt>
- <dd>Used to list alternate ways to reach this service.</dd>
- <dt>{{HTTPHeader("Date")}}</dt>
- <dd>Contains the date and time at which the message was originated.</dd>
- <dt>{{HTTPHeader("Large-Allocation")}}</dt>
- <dd>Tells the browser that the page being loaded is going to want to perform a large allocation.</dd>
- <dt>{{HTTPHeader("Link")}}</dt>
- <dd>The <code><a href="https://tools.ietf.org/html/rfc5988#section-5">Link</a></code> entity-header field provides a means for serialising one or more links in HTTP headers. It is semantically equivalent to the HTML {{HTMLElement("link")}} element.</dd>
- <dt>{{HTTPHeader("Push-Policy")}} {{experimental_inline}}</dt>
- <dd>A <code><a href="https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00#section-3.2">Push-Policy</a></code> defines the server behaviour regarding push when processing a request.</dd>
- <dt>{{HTTPHeader("Retry-After")}}</dt>
- <dd>Indicates how long the user agent should wait before making a follow-up request.</dd>
- <dt>{{HTTPHeader("Signature")}} {{experimental_inline}}</dt>
- <dd>The <code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.1">Signature</a></code> header field conveys a list of signatures for an exchange, each one accompanied by information about how to determine the authority of and refresh that signature.</dd>
- <dt>{{HTTPHeader("Signed-Headers")}} {{experimental_inline}}</dt>
- <dd>The <code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.5.1.2">Signed-Headers</a></code> header field identifies an ordered list of response header fields to include in a signature.</dd>
- <dt>{{HTTPHeader("Server-Timing")}}</dt>
- <dd>Communicates one or more metrics and descriptions for the given request-response cycle.</dd>
- <dt>{{HTTPHeader("Service-Worker-Allowed")}}</dt>
- <dd>Used to remove the <a href="https://w3c.github.io/ServiceWorker/#path-restriction">path restriction</a> by including this header <a href="https://w3c.github.io/ServiceWorker/#service-worker-script-response">in the response of the Service Worker script</a>.</dd>
- <dt>{{HTTPHeader("SourceMap")}}</dt>
- <dd>Links generated code to a <a href="/en-US/docs/Tools/Debugger/How_to/Use_a_source_map">source map</a>.</dd>
- <dt>{{HTTPHeader("Upgrade")}}</dt>
- <dd>The relevant RFC document for the <a href="https://tools.ietf.org/html/rfc7230#section-6.7">Upgrade header field is RFC 7230, section 6.7</a>. The standard establishes rules for upgrading or changing to a different protocol on the current client, server, transport protocol connection. For example, this header standard allows a client to change from HTTP 1.1 to HTTP 2.0, assuming the server decides to acknowledge and implement the Upgrade header field. Neither party is required to accept the terms specified in the Upgrade header field. It can be used in both client and server headers. If the Upgrade header field is specified, then the sender MUST also send the Connection header field with the upgrade option specified. For details on the Connection header field <a href="https://tools.ietf.org/html/rfc7230#section-6.1">please see section 6.1 of the aforementioned RFC</a>.</dd>
- <dt>{{HTTPHeader("X-DNS-Prefetch-Control")}}</dt>
- <dd>Controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.</dd>
- <dt>{{HTTPHeader("X-Firefox-Spdy")}} {{deprecated_inline}} {{non-standard_inline}}</dt>
- <dd>...</dd>
- <dt>{{HTTPHeader("X-Pingback")}} {{non-standard_inline}}</dt>
- <dd>...</dd>
- <dt>{{HTTPHeader("X-Requested-With")}}</dt>
- <dd>...</dd>
- <dt>{{HTTPHeader("X-Robots-Tag")}}{{non-standard_inline}}</dt>
- <dd>The <code><a href="https://developers.google.com/search/reference/robots_meta_tag#xrobotstag">X-Robots-Tag</a></code> HTTP header is used to indicate how a web page is to be indexed within public search engine results. The header is effectively equivalent to <code>&lt;meta name="robots" content="..."&gt;</code>.</dd>
- <dt>{{HTTPHeader("X-UA-Compatible")}} {{non-standard_inline}}</dt>
- <dd>Used by Internet Explorer to signal which document mode to use.</dd>
-</dl>
-
-<h2 id="Contributing">Contributing</h2>
-
-<p>You can help by <a href="/en-US/docs/MDN/Contribute/Howto/Document_an_HTTP_header">writing new entries</a> or improving the existing ones.</p>
-
-<h2 id="See_also">See also</h2>
-
-<ul>
- <li><a href="https://en.wikipedia.org/wiki/List_of_HTTP_header_fields">Wikipedia page on List of HTTP headers</a></li>
- <li><a href="https://www.iana.org/assignments/message-headers/perm-headers.html">IANA registry</a></li>
- <li><a href="https://httpwg.org/specs/">HTTP Working Group</a></li>
-</ul>
diff --git a/files/th/web/http/index.html b/files/th/web/http/index.html
deleted file mode 100644
index 832303c8c0..0000000000
--- a/files/th/web/http/index.html
+++ /dev/null
@@ -1,227 +0,0 @@
----
-title: HTTP
-slug: Web/HTTP
-tags:
-  - HTTP
-  - Headers
-  - NeedsTranslation
-  - TopicStub
-translation_of: Web/HTTP
----
-<p>{{ HTTPSidebar }}</p>
-
-<p><strong><dfn>Hypertext Transfer Protocol (HTTP)</dfn></strong> เป็นโปรโตคอลในระดับชั้นแอพพลิเคชัน(<a class="external" href="http://en.wikipedia.org/wiki/Application_Layer" title="http://en.wikipedia.org/wiki/Application_Layer">application-layer</a>) ที่ใช้สำหรับการจัดส่งเอกสารประเภท hypermedia อย่างเช่นเอกสาร HTML และถูกออกแบบมาเพื่อใช้งานในการติดต่อสื่อสารระหว่าง web browser กับ web server และสามารถนำไปใช้ในจุดประสงค์อื่น ๆ ได้ด้วย ซึ่งรูปแบบการสื่อสารของโปรโตคอล HTTP เป็นไปตามโมเดลการสื่อสารแบบเครื่องลูกข่าย-แม่ข่าย(<a class="external" href="http://en.wikipedia.org/wiki/Client%E2%80%93server_model" title="http://en.wikipedia.org/wiki/Client–server_model">client-server model</a>) ที่เครื่องลูกข่ายจะสร้าง connection เพื่อส่ง request ไปยังเครื่องแม่ข่าย และรอจนกว่าจะได้ response กลับมาจากเครื่องแม่ข่าย นอกจากนั้น HTTP เป็นโปรโตคอลแบบ <a class="external" href="http://en.wikipedia.org/wiki/Stateless_protocol" title="http://en.wikipedia.org/wiki/Stateless_protocol">stateless protocol</a> เป็นลักษณะที่เครื่องแม่ข่ายไม่มีการจัดเก็บข้อมูล(state) ใด ๆ ที่เกิดขึ้นระหว่าง request เพราะข้อมูลแต่ละ request สามารถทำความเข้าใจได้ในตัวมันเอง และเนื่องจาก HTTP เป็นโปรโตคอลที่ใช้งานในระดับชั้นแอพพลิเคชัน ซึ่งอยู่ในระดับชั้นที่สูงกว่าโปรโตคอลในระดับล่างอย่าง TCP/IP ที่อยู่ในระดับ <a class="external" href="http://en.wikipedia.org/wiki/Transport_Layer" title="http://en.wikipedia.org/wiki/Transport_Layer">transport layer</a> มันจึงสามารถใช้รูปแบบการติดต่อสื่อสารที่มีความน่าเชื่อถือของโปรโตคอลต่าง ๆ ในระดับชั้น transport ได้ อย่างเช่น อาจจะเลือกใช้โปรโตคอล RUDP ที่มีความน่าเชื่อถือกว่า UDP ที่มีโอกาสสูญเสียข้อมูลไปโดยไม่รู้ตัวได้</p>
-
-<h2 class="Documentation" id="Documentation" name="Documentation">Documentation</h2>
-
-<dl>
- <dt><a href="/en-US/docs/Web/HTTP/Headers" title="/en-US/docs/HTTP/Headers">HTTP Headers</a></dt>
- <dd>HTTP message headers ใช้ในการบรรยายเกี่ยวกับ resource หรือ พฤติกรรมของเครื่องแม่ข่าย(server) หรือ เครื่องลูกข่าย(client) การสร้าง HTTP header ขึ้นใช้งานเอง สามารถทำได้ด้วยการเติมอักษร "X-" นำหน้าชื่อ header ที่ต้องการ โดย Header มาตรฐานต่าง ๆ สามารถศึกษาเพิ่มเติมได้จาก <a class="external" href="http://www.iana.org/assignments/message-headers/perm-headers.html" title="http://www.iana.org/assignments/message-headers/perm-headers.html">IANA registry</a> เนื้อหาต้นฉบับจะถูกนิยามไว้ใน <a class="external" href="http://tools.ietf.org/html/rfc4229" title="http://tools.ietf.org/html/rfc4229">RFC 4229</a> โดยมี IANA เป็นผู้ดูแลเกี่ยวกับ<a href="http://www.iana.org/assignments/message-headers/prov-headers.html">การลงทะเบียนเพื่อเสนอ HTTP header รูปแบบใหม่</a></dd>
- <dt><a href="/en/Web_Development/HTTP_cookies" title="HTTP cookies">HTTP cookies</a></dt>
- <dd>การทำงานของ cookie ได้มีการนิยามไว้โดย <a class="external" href="http://tools.ietf.org/html/rfc6265">RFC 6265</a> โดยกระบวนการเกิดขึ้นหลังจากที่เครื่องแม่ข่ายได้รับ HTTP request แล้ว เครื่องแม่ข่ายจะสามารถส่ง header ชื่อ Set-Cookie ไปกับ response ให้กับเครื่องลูกข่าย หลังจากนั้นเมื่อใดก็ตามที่เครื่องลูกข่ายต้องการส่ง request ไปยังเครื่องแม่ข่าย ค่าของ cookie จะถูกส่งไปพร้อม request ด้วยเสมอ ในรูปแบบของ HTTP header ชื่อ Cookie นอกจากนั้นยังสามารถกำหนดวันและเวลาหมดอายุของ cookie และการจำกัดการเข้าถึง domain และ path ได้</dd>
- <dt><a href="/en-US/docs/HTTP/Basic_access_authentication" title="/en-US/docs/HTTP/Basic_access_authentication">Basic access authentication</a></dt>
- <dd>ในบริบทของการติดต่อสื่อสารบนโปรโตคอล HTTP นั้น การพิสูจน์ตัวจริงแบบพื้นฐานเพื่อการเข้าถึง <strong>(basic access authentication)</strong> เป็นวิธีการสำหรับ <a href="https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.userAgent" title="HTTP user agent">HTTP user agent</a> ในการ request ไปยังเครื่องแม่ข่ายที่ต้องมีการจัดเตรียมรหัสผู้ใช้งาน (username) และรหัสผ่าน (password) เพื่อใช้ในการพิสูจน์ตัวจริง</dd>
- <dt><a href="/en/HTTP_Pipelining_FAQ" title="https://developer.mozilla.org/en/HTTP_Pipelining_FAQ">HTTP pipelining FAQ</a></dt>
- <dd>HTTP/1.1 Pipelining FAQ</dd>
- <dt><a href="/en-US/docs/HTTP/Access_control_CORS" title="/en-US/docs/HTTP/Access_control_CORS">HTTP access control (CORS)</a></dt>
- <dd><strong>Cross-site HTTP requests</strong> are <a href="https://developer.mozilla.org/en/HTTP" title="en/HTTP">HTTP</a> requests for resources from a <strong>different domain</strong> than the domain of the resource making the request.  For instance, a resource loaded from Domain A (<code><span class="nowiki">http://domaina.example</span></code>) such as an HTML web page, makes a request for a resource on Domain B (<span class="nowiki">http://domainb.foo</span>), such as an image, using the <code>img</code> element (<code><span class="nowiki">http://domainb.foo/image.jpg</span></code>).  This occurs very commonly on the web today — pages load a number of resources in a cross-site manner, including CSS stylesheets, images and scripts, and other resources.</dd>
- <dt><a href="/En/Controlling_DNS_prefetching" title="En/Controlling DNS prefetching">Controlling DNS prefetching</a></dt>
- <dd>Firefox 3.5 performs <strong>DNS prefetching</strong>.  This is a feature by which Firefox proactively performs domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth. This prefetching is performed in the background, so that the DNS is likely to already have been resolved by the time the referenced items are actually needed.  This reduces latency when, for example, the user actually clicks a link.</dd>
- <dt><a href="/en-US/docs/Web/HTTP/Response_codes" title="/en-US/docs/HTTP/HTTP_response_codes">HTTP response codes</a></dt>
- <dd>HTTP Response Codes indicate whether a specific <a href="https://developer.mozilla.org/en/HTTP" title="en/HTTP">HTTP</a> requests has been successfully completed. Responses are grouped in five classes: informational responses, successful responses, redirections, client errors, and servers errors.</dd>
-</dl>
-
-<h2 id="A_brief_history_of_HTTP">A brief history of HTTP</h2>
-
-<p>Since its original conception, as a protocol with one single method (GET) and returning only HTML pages, the HTTP protocol went through several revisions. The first documented version was HTTP/0.9 in 1991, corresponding to the original version. Very simple, it has a rudimentary search capability via the HTML {{ HTMLElement("isindex") }} element and an extension of the URL using the '<span style="font-family: courier new;">?</span>' character.</p>
-
-<p>Then, in 1992, a version was published that became, with some minor changes, HTTP/1.0 (finalized in <a class="external" href="http://tools.ietf.org/html/rfc1945" title="http://tools.ietf.org/html/rfc1945">RFC 1945</a> in May 1996). One major improvement over the previous version was the ability to transmit files of different types, like images, videos, scripts, CSS documents, and so on, instead of only HTML files: this is achieved by using <a class="external" href="http://en.wikipedia.org/wiki/Mime_types" title="http://en.wikipedia.org/wiki/Mime_types">MIME types</a> in conjunction with the <code>Content-Type:</code> header.</p>
-
-<p>In 1995, the <a class="external" href="http://www.ietf.org/" title="http://www.ietf.org/">IETF</a>  began developing a new version of HTTP, which would become HTTP/1.1. It quickly spread into wide usage, and it was officially standardized in 1997 in <a class="external" href="http://tools.ietf.org/html/rfc2068" title="http://tools.ietf.org/html/rfc2068">RFC 2068</a>, with minor fixes in <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a> two years later.</p>
-
-<p>HTTP/1.1 brought the ability to reuse established connections for subsequent requests, greatly improving the performance of the protocol by lowering the latency between them; this is especially useful with complex HTML documents that need to fetch several subsequent files, like images or style sheets. It also brought the <code>Host:</code> header, which allows a single server, listening on a specific port, to receive requests for several websites; this paved the way for colocating numerous websites on one single server, greatly reducing the cost of hosting.</p>
-
-<p>Since then, the HTTP protocol evolved by adding new <a href="/en/HTTP/Headers" title="en/HTTP/Headers">headers</a>, defining new behaviors without the need to fundamentally change the protocol. Unknown headers are simply ignored by servers or clients.</p>
-
-<p>HTTP/1.1 is currently being revised by the <a class="external" href="http://tools.ietf.org/wg/httpbis/" title="http://tools.ietf.org/wg/httpbis/">IETF HTTPbis Working Group</a>.</p>
-
-<ul>
-</ul>
-
-<h2 id="HTTP_request_methods">HTTP request methods</h2>
-
-<p>The request method indicates the action to be performed by the server. The HTTP/1.1 standard defines seven methods and allows other methods to be added later. Over the years, a few ones have been added in standards like <a href="/en/WebDAV" title="en/WebDAV">WebDAV</a>. The  <a class="external" href="http://tools.ietf.org/wg/httpbis/" rel="external nofollow" title="http://tools.ietf.org/wg/httpbis/">IETF HTTPbis Working Group</a> is currently working on an IANA registry to list them all. If a server receives a request method that it doesn't know, it must return a <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#501" rel="internal" title="en/HTTP/HTTP response codes#501">501 Not implemented</a></span> response; if it knows the method but is configured not to answer it, it must return a <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#501" rel="internal" title="en/HTTP/HTTP response codes#501">405 Method not allowed</a></span> response. Two methods are required to be supported: HEAD and GET; all others are optional.</p>
-
-<p>Two specific semantics are defined in the standard and are crucial for web developers: the <em>safety</em> property and the <em>idempotent</em> property.</p>
-
-<h3 id="Safe_methods">Safe methods</h3>
-
-<p>A <dfn>safe method</dfn> is a method that doesn't have any side-effects on the server. In other words, this property means that the method must be used only for <em>retrieval</em> of data. The safe HTTP methods defined in HTTP/1.1 are:</p>
-
-<ul>
- <li>GET, used to retrieve information identified by the request URI. This information may be generated on the fly or the GET may be conditional if any of the {{ httpheader("If-Modified-Since") }}, {{ httpheader("If-Unmodified-Since") }}, {{ httpheader("If-Match") }}, {{ httpheader("If-None-Match") }} or {{ httpheader("If-Range") }} HTTP headers are set. In that latter case the information is only sent back if all the conditions are fulfilled.</li>
- <li>HEAD, which is identical to GET but without the message body sent.</li>
-</ul>
-
-<div class="note"><strong>Notes: </strong>
-
-<ul>
- <li>Any safe method is also <em>idempotent</em>.</li>
- <li>Not having any side-effects means, for the GET method, that it <strong>must</strong> not be used to trigger an action outside the server, like an order in an e-commerce site. If a side-effect is wanted, a non-<em>idempotent</em> method should be used, like POST.</li>
- <li>When a page is generated on the fly by a script, the script engine may calculate the page as if it was requested by a GET and then strip the data block. This does not cause problem as long as the GET as implemented in the script is <em>safe</em>, but if it has any side-effects (like triggering an order on an e-commerce site), the HEAD method will trigger it too. It is up to the web developer to ensure that both the GET and HEAD method are safely implemented.</li>
-</ul>
-</div>
-
-<h3 id="Idempotent_methods">Idempotent methods</h3>
-
-<p>An <dfn>idempotent method</dfn> is a method such that the side-effects on the server of several identical requests with the method are the same as the side-effects of one single request.</p>
-
-<ul>
- <li>HEAD and GET, like any safe method, are also idempotent, as a safe method doesn't have side-effects on the server.</li>
- <li>PUT is the way to upload a new resource on the server. If the resource already exists and is different, it is replaced; if it doesn't exist, it is created.</li>
- <li>DELETE removes a resource from the server.</li>
-</ul>
-
-<h3 id="Other_methods">Other methods</h3>
-
-<ul>
- <li>POST is the way to trigger an action on the server. It has side-effects and can be used to trigger an order, to modify a database, to post a message in a forum, and so on.</li>
- <li>OPTIONS is a request for communication options available on the chain between the client and the server (through eventual proxies); this method is typically sent before any <a href="/En/HTTP_access_control#Preflighted_requests" title="en/HTTP access control#Preflighted requests">preflighted cross-origin request</a>, in order to know whether it is safe to do it.
-  <div class="note"><strong>Note:</strong> <a href="/En/HTTP_access_control#Preflighted_requests" title="en/HTTP access control#Preflighted requests">Preflighted cross-origin requests</a> cannot be done on servers which don't allow or support the OPTIONS method.</div>
- </li>
- <li>TRACE is a kind of ping between the client and the server (through eventual proxies).</li>
-</ul>
-
-<p>Many more methods, such as PROPFIND or PATCH are defined in other standards-track RFCs of the IETF, like WebDAV.</p>
-
-<p>The CONNECT method is defined in <a class="external" href="http://tools.ietf.org/html/rfc2817" title="http://tools.ietf.org/html/rfc2817">RFC 2817</a>.</p>
-
-<h3 id="HTTP_Requests_Methods_in_HTML_Forms">HTTP Requests Methods in HTML Forms</h3>
-
-<p>In HTML, different HTTP request methods can be specified in the {{ htmlattrxref("method", "form") }} attribute of the {{ HTMLElement("form") }} element, but also to the {{ htmlattrxref("formmethod", "input") }} of the {{ HTMLElement("input") }} and {{ HTMLElement("button") }} elements. But not all HTTP methods can be used with these attributes; only GET and POST method are allowed by the HTML specification. See <a href="http://programmers.stackexchange.com/a/211790">this StackExchange answer why other HTTP request methods are not allowed by the HTML specification</a>.</p>
-
-<div class="note"><strong>Note</strong>: The choice of a GET or POST method for HTML forms is not neutral. Because the GET method is a <a href="/en/HTTP#Safe_methods" title="https://developer.mozilla.org/en/HTTP#Safe_methods">safe method</a>, it should be used only in cases where no side-effect is expected; e.g., it shouldn't be used to transmit an order, as this order is a side-effect. In all cases where such side-effects are expected, the POST method should be used.</div>
-
-<h2 id="HTTP_response_codes">HTTP response codes</h2>
-
-<p>When answering a client request, the server sends back a three-digit number indicating whether the request was successfully processed. These codes can be grouped in five categories:</p>
-
-<ul>
- <li><dfn>Informational responses</dfn> (of the form <code>1xx</code>) are provisional responses. Most of the time neither the end user, nor the web developer or webmaster should have to bother with these. The most common is the <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#100" title="en/HTTP/HTTP response codes#100">100 Continue</a></span> response, indicating that the client should continue to send its request.
-
-  <div class="note"><strong>Note:</strong> No information response codes were defined in the HTTP/1.0, and therefore they must not be sent back when this version of the protocol is used.</div>
- </li>
- <li><dfn>Success responses</dfn> (of the form <code>2xx</code>) are for successfully processed requests. The <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#200" title="en/HTTP/HTTP response codes#200">200 OK</a></span> response is by far the most common of these responses, but the <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#206" title="en/HTTP/HTTP response codes#206">206 Partial Content</a></span> is also often seen when fetching a file or some media data like video or audio.</li>
- <li><dfn>Redirection responses</dfn> (of the form <code>3xx</code>) indicate that the resource that the client requested has moved and the server is not able to serve it directly. Most of these responses contain some location information telling where to find the requested resource; user-agents often then retrieve it without further user interaction. The most common responses of this type are <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#301" title="en/HTTP/HTTP response codes#301">301 Moved Permanently</a></span>, indicating that the URI given is no longer valid and has been moved to another place, and <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#302" title="en/HTTP/HTTP response codes#302">302 Found</a></span> which indicates that the resource has been <em>temporarily</em> moved to another place.
-  <div class="note"><strong>Note:</strong> For webmasters, it is recommended to set up a <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#301" title="en/HTTP/HTTP response codes#301">301 Moved Permanently</a></span> redirection when moving pages to another URI, during a site reorganization for example. That allows users following links to still reach the resource and it also teaches search engines and other services the new location of the resource, so that they can transfer their metadata to it. It is also important to add adequate cache headers to the <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#301" title="en/HTTP/HTTP response codes#301">301 Moved Permanently</a></span> response so that this information is cached by the client and prevents it from making unnecessary requests to the original URI prior to fetching the resource itself.</div>
- </li>
- <li><dfn>Client error responses</dfn> (of the form <code>4xx</code>) indicate that the request sent by the client is either invalid, incomplete, or doesn't have enough rights to be performed. The most common such response is <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#404" title="en/HTTP/HTTP response codes#404">404 Not Found</a></span> which is sent back when the URI requested doesn't exist, but a few others are often presented to the end user, like <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#400" title="en/HTTP/HTTP response codes#400">400 Bad Request</a></span> sent when the request isn't a valid HTTP request (as this shouldn't happen but may indicate a bug into the user agent or, less likely, the server) or <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#403" title="en/HTTP/HTTP response codes#403">403 Forbidden</a></span>, sent when the client request a resource that does exist but isn't allowed to be transmitted (like a directory content).</li>
- <li><dfn>Server error responses</dfn> (of the form <code>5xx</code>) indicate that the server had a problem handling the valid client request. The two most common such responses are <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#500" title="en/HTTP/HTTP response codes#500">500 Internal Server Error</a></span>, a generic error code indicating a bug in the server or <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#503" title="en/HTTP/HTTP response codes#503">503 Service Unavailable</a></span> indicating that the server cannot process the request due to a temporary problem, like a disabled service for maintenance purposes or the non-availability of a database.</li>
-</ul>
-
-<p>A web developer shouldn't encounter many other response codes, but people building requests using the <code><a href="/en/nsIXMLHttpRequest" title="en/XMLHttpRequest">XMLHTTPRequest</a></code> function may hit <a href="/en/HTTP/HTTP_response_codes" title="en/HTTP/HTTP response codes">less usual response codes</a>.</p>
-
-<h3 id="More_on_redirection_responses">More on redirection responses</h3>
-
-<p>Starting in Gecko 9.0 {{ geckoRelease("9.0") }}, redirections (such as 301 and 307) that specify a <code>javascript:</code> URI are no longer performed. Instead, a bad connection error is presented. This helps avoid cross-site scripting attacks. See {{ bug(255119) }} if you want more details.</p>
-
-<h2 id="HTTP_headers">HTTP headers</h2>
-
-<p>HTTP headers allow the client and the server to pass additional information with the request or the response. A request header consists of its case-insensitive name followed by a colon ':', then by its value (without CRLF in it). Leading white space before the value is ignored.</p>
-
-<p>Headers are grouped according the context in which they may appear:</p>
-
-<dl>
- <dt>General headers</dt>
- <dd>These headers apply to both requests and responses but are unrelated to the data eventually transmitted in the body. They therefore apply only to the message being transmitted. There are only a few of them and new ones cannot be added without increasing the version number of the HTTP protocol. The exhaustive list for HTTP/1.1 is {{ httpheader("Cache-Control") }}, {{ httpheader("Connection") }}, {{ httpheader("Date") }}, {{ httpheader("Pragma") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }}, {{ httpheader("Upgrade") }}, {{ httpheader("Via") }} and {{ httpheader("Warning") }}.</dd>
- <dt>Request headers</dt>
- <dd>These headers give more precise information about the resource to be fetched or about the client itself. Among them one can find <a href="/en/HTTP_Caching_FAQ" title="en/HTTP Caching FAQ">cache-related headers</a>, transforming a GET method in a conditional GET, like {{ httpheader("If-Modified-Since") }}, user-preference information like {{ httpheader("Accept-Language") }} or {{ httpheader("Accept-Charset") }} or plain client information like {{ httpheader("User-Agent") }}. New request headers cannot officially be added without increasing the version number of the HTTP protocol. But, it is common for new request headers to be added if both the server and the client agree on their meaning. In that case, a client should not assume that they will be handled adequately by the server; unknown request headers are handled as <em>entity headers</em>.</dd>
- <dt>Response headers</dt>
- <dd>These headers give more information about the resource sent back, like its real location ({{ httpheader("Location") }}) or about the server itself, like its name and version ({{ httpheader("Server") }}). New response headers cannot be added without increasing the version number of the HTTP protocol. But, it is common for new response headers to be added if both the server and the client agree on their meaning. In that case, a server should not assume that they will be handled adequately by the client ; unknown response headers are handled as <em>entity headers</em>.</dd>
- <dt>Entity headers</dt>
- <dd>These headers give more information about the body of the entity, like its length ({{ httpheader("Content-Length") }}), an identifying hash ({{ httpheader("Content-MD5") }}), or its MIME-type ({{ httpheader("Content-Type") }}). New entity headers can be added without increasing the version number of the HTTP protocol.</dd>
-</dl>
-
-<p>Headers can also be grouped according to how caching and non-caching proxies handle them:</p>
-
-<dl>
- <dt>End-to-end headers</dt>
- <dd>These headers must be transmitted to the final recipient of the message; that is, the server for a request message or the client for a response message. Such a header means that intermediate proxies must retransmit it unmodified and also that caches must store it.</dd>
- <dt>Hop-by-hop headers</dt>
- <dd>These headers are meaningful only for a single transport-level connection and must not be retransmitted by proxies or cached. Such headers are: {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailers") }}, {{ httpheader("Transfer-Encoding") }} and {{ httpheader("Upgrade") }}. Note that only hop-by-hop headers may be set using the {{ httpheader("Connection") }} general header.</dd>
-</dl>
-
-<p>In order to learn about the specific semantic of each header, see its entry in the <a href="/en/HTTP/Headers" title="en/HTTP/Headers">comprehensive list of HTTP headers</a>.</p>
-
-<h3 id="Useful_request_headers">Useful request headers</h3>
-
-<p>Among the numerous <a href="/en/HTTP/Headers" title="en/HTTP/Headers">HTTP request headers</a>, several are especially useful when set correctly. If you are building your own requests, by using <code><a href="/en/DOM/XMLHttpRequest" title="en/XMLHTTPRequest">XMLHTTPRequest</a></code> or when writing an extension and sending <a href="/en/Setting_HTTP_request_headers" title="en/Setting HTTP request headers">custom HTTP requests via XPCOM</a>, then it is important to ensure the presence of headers that are often set by browsers based on the preferences of the user.</p>
-
-<dl>
- <dt>Controlling the language of the resource</dt>
- <dd>Most user-agents, like Firefox, allow the user to set a preference for the language for receiving a resource. The browser translate this into an {{ httpheader("Accept-Language") }} header. It is good practice for web developers, when building specific HTTP requests, to include such a header too.</dd>
- <dt>Using conditional GET</dt>
- <dd>Caching is a major tool to accelerate the display of web pages. Even when parts of a webpage are refreshed via an <code><a href="/en/DOM/XMLHttpRequest" title="en/XMLHTTPRequest">XMLHTTPRequest</a></code>:, it is a good idea to use the {{ httpheader("If-Modified-Since") }} header (and other similar ones) in order to fetch the new content only if it has changed. This approach lowers the burden on the network.</dd>
-</dl>
-
-<h3 id="Useful_response_headers">Useful response headers</h3>
-
-<p>The configuration of a web server is a critical part to ensure good performance and optimal security of a web site. Among the <a href="/en/HTTP/Headers" title="en/HTTP/Headers">numerous HTTP response headers</a>, several are of specific importance and should be configured on the server</p>
-
-<h4 id="Restricting_framing">Restricting framing</h4>
-
-<p>Several cross-site scripting (XSS) attacks take advantage of the ability to put third-party content inside an {{ HTMLElement("frame") }} or {{ HTMLElement("iframe") }}. In order to mitigate that risk, modern browsers have introduced the <code><a href="/en/Security/CSP/CSP_policy_directives#frame-ancestors" title="en/The X-FRAME-OPTIONS response header">CSP frame-ancestors directive</a></code>. By setting it with the value <code>'none'</code>, it prevents the browser from displaying this resource inside of a frame. Using it on critical resources (like those containing a formularies or critical information) will reduce the risk caused by XSS attacks. Note that this specific HTTP response header is not the only way to mitigate XSS risks; other techniques, like setting some <a href="/en/Security/CSP/Introducing_Content_Security_Policy" title="en/Security/CSP/Introducing Content Security Policy">Content Security Policies</a>, may be helpful too.</p>
-
-<h4 id="Compression">Compression</h4>
-
-<p>Minimizing the amount of data transferred accelerates the display of a web page. Though most techniques, like <a href="/en/CSS/CSS_Sprites" title="en/CSS/CSS Sprites">CSS Sprites</a>, should be applied on the site itself, compression of data must be set at the web server level. If set, resources requested by the client with an {{ httpheader("Accept-Encoding") }} request header are compressed using the appropriate method and sent back with a {{ httpheader("Content-Encoding") }} response header. Setting these in Apache 2 servers is done by using the <a class="external" href="http://httpd.apache.org/docs/2.0/mod/mod_deflate.html" title="http://httpd.apache.org/docs/2.0/mod/mod_deflate.html">mod_deflate module</a>.</p>
-
-<div class="note"><strong>Note:</strong> Be aware that not all data formats can be efficiently compressed. Already-compressed media data, like JPEG images or most audio and video formats, do not shrink using another pass of compression. In fact, they often become larger due to the overhead of the compression method. It is important not to try to compress these resource types any further; there is no advantage in size and the compression/decompression mechanism is resource-intensive.</div>
-
-<h4 id="Controlling_cache">Controlling cache</h4>
-
-<p><a href="/en/HTTP_Caching_FAQ" title="en/HTTP Caching FAQ">HTTP Caching</a> is a technique that prevents the same resource from being fetched several times if it hasn't change. Configuring the server with the correct response headers allows the user-agent to adequately cache the data. In order to do that, be sure that:</p>
-
-<ul>
- <li>Any static resource provides an {{ httpheader("Expires") }} response header that is set to far in the future. That way, the resource may stay in the cache until the user-agent flushes it for its own reasons (like reaching its cache size limit).
-  <div class="note"><strong>Note: </strong>On Apache, use the ExpiresDefault directive in your .htaccess to define a relative expires: <code>ExpiresDefault "access plus 1 month"</code>.</div>
- </li>
- <li>Any dynamic resource provides a {{ httpheader("Cache-control") }} response header. Theoretically, any HTTP request done through a <a href="/en/HTTP#Safe_Methods" title="en/HTTP#Safe Methods">safe method</a> (GET or HEAD) or even through a solely <a href="/en/HTTP#Idempotent_Methods" title="en/HTTP#Idempotent Methods">idempotent one</a> (DELETE, PUT) may be cached; but in practice careful study is needed to determine if the caching of the response may lead to inappropriate side-effects.</li>
-</ul>
-
-<h4 id="Setting_the_correct_MIME_types">Setting the correct MIME types</h4>
-
-<p>The MIME type is the mechanism to tell the client the kind of document transmitted: the extension of a file name has no meaning on the web. It is therefore important that the server is correctly set up so that the correct MIME type is transmitted with each document: user-agents often use this MIME-type to determine what default action to do when a resource is fetched.</p>
-
-<div class="note"><strong>Note: </strong>
-
-<ul>
- <li>On Apache, one can match file extensions with a given MIME type in the .htaccess using the <font face="Verdana,Helvetica,Arial"><span style="font-family: courier new;"><code>AddType</code></span> type directive like</font><code> AddType image/jpeg jpg.</code></li>
- <li>Most web servers send unknown-type resources using the default <code>application/octet-stream</code> MIME type; for security reasons, most browsers, like Firefox, do not allow setting a custom default action for such resources and force the user to store it to disk in order to use it. Some common cases of often incorrectly configured servers happens for the following file types:
-  <ul>
-   <li>
-    <p>Rar-encoded files. The ideal would be to be able to set the real type of the encoded files; this often is not possible (as it may not be known to the server and these files may contains several resource of different types). In that case, configure the server to send the <code>application/x-rar-compressed </code>MIME type or some users won't be able to define a useful default action for them.</p>
-   </li>
-   <li>
-    <p>Audio and video files. Only resources with the proper MIME Type will be recognized and played, using a {{ HTMLElement("video") }} or {{ HTMLElement("audio") }} elements. Be sure to <a href="/En/Media_formats_supported_by_the_audio_and_video_elements" title="En/Media formats supported by the audio and video elements">use the correct MIME type for audio and video resources</a>.</p>
-   </li>
-   <li>
-    <p>Proprietary file types. Pay special attention when serving a proprietary file type. Be sure not to forget to add an x-prefixed type for it; otherwise, special handling won't be possible. This is especially true with resources using the <a class="external" href="http://en.wikipedia.org/wiki/Keyhole_Markup_Language" title="http://en.wikipedia.org/wiki/Keyhole_Markup_Language">Keyhole Markup Language</a>, which should be served as <code>application/vnd.google-earth.kml+xml </code>for an optimal user experience.</p>
-   </li>
-  </ul>
- </li>
-</ul>
-</div>
-
-<h2 id="See_also">See also</h2>
-
-<ul>
- <li><a href="/En/Controlling_DNS_prefetching" title="En/Controlling DNS prefetching">Controlling DNS prefetching</a></li>
- <li>The <a href="/en/HTTP_Pipelining_FAQ" title="https://developer.mozilla.org/en/HTTP_Pipelining_FAQ">HTTP pipelining FAQ</a></li>
- <li><a href="/en/Web_Development/HTTP_cookies" title="HTTP cookies">HTTP cookies</a></li>
- <li><a href="/en-US/docs/HTTP/Headers" title="/en-US/docs/HTTP/Headers">HTTP Headers</a></li>
- <li><a href="/en-US/docs/HTTP/Basic_access_authentication" title="/en-US/docs/HTTP/Basic_access_authentication">Basic access authentication</a></li>
- <li><a href="/en-US/docs/HTTP/Access_control_CORS" title="/en-US/docs/HTTP/Access_control_CORS">HTTP access control (CORS)</a></li>
-</ul>
-
-<p>{{ languages( { "ja": "ja/HTTP"} ) }}</p>
diff --git a/files/th/web/http/status/201/index.html b/files/th/web/http/status/201/index.html
deleted file mode 100644
index 9cef9d44f9..0000000000
--- a/files/th/web/http/status/201/index.html
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: 201 Created
-slug: Web/HTTP/Status/201
-translation_of: Web/HTTP/Status/201
----
-<div>{{HTTPSidebar}}</div>
-
-<p>หมายเลขสถานะของ HTTP หมายเลข <code><strong>201 Created</strong></code> แสดงถึงการร้องขอนั้นสำเร็จและทำให้เกิดการสร้างทรัพยากรใหม่ ทรัพยากรใหม่นี้ถูกสร้างสำเร็จก่อนที่การตอบสนองจะถูกส่งกลับมา และทรัพยากรใหม่นี้ถูกส่งกลับมากับเนื้อหาของข้อความด้วย ที่ตั้งของมันเป็นได้ทั้ง URL ที่ใช้ในการร้องขอ หรือเนื้อหาในส่วน header ของ {{HTTPHeader("Location")}}</p>
-
-<p>โดยปกติแล้วการใช้งานของหมายเลขสถานะนี้จะเป็นผลมาจากการร้องขอแบบ {{HTTPMethod("PUT")}}</p>
-
-<h2 id="สถานะ">สถานะ</h2>
-
-<pre class="syntaxbox">201 Created</pre>
-
-<h2 id="ข้อกำหนด">ข้อกำหนด</h2>
-
-<table class="standard-table">
- <tbody>
-  <tr>
-   <th scope="col">ข้อกำหนด</th>
-   <th scope="col">หัวข้อ</th>
-  </tr>
-  <tr>
-   <td>{{RFC("7231", "201 Created" , "6.3.2")}}</td>
-   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
-  </tr>
- </tbody>
-</table>
-
-<h2 id="การเข้ากันได้ของเบราเซอร์">การเข้ากันได้ของเบราเซอร์</h2>
-
-<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
-
-<p>{{Compat("http.status.201")}}</p>
-
-<h2 id="ดูสิ่งนี้ด้วย">ดูสิ่งนี้ด้วย</h2>
-
-<ul>
- <li><a href="/en-US/docs/Web/HTTP/Methods">HTTP request methods</a></li>
-</ul>
diff --git a/files/th/web/http/status/index.html b/files/th/web/http/status/index.html
deleted file mode 100644
index e490502369..0000000000
--- a/files/th/web/http/status/index.html
+++ /dev/null
@@ -1,171 +0,0 @@
----
-title: HTTP response status codes
-slug: Web/HTTP/Status
-tags:
-  - HTTP
-  - NeedsTranslation
-  - Status codes
-  - TopicStub
-translation_of: Web/HTTP/Status
----
-<div>{{HTTPSidebar}}</div>
-
-<p>HTTP response status codes indicate whether a specific <a href="/en-US/docs/Web/HTTP">HTTP</a> request has been successfully completed. Responses are grouped in five classes: informational responses, successful responses, redirects, client errors, and servers errors. Status codes are defined by <a href="https://tools.ietf.org/html/rfc2616#section-10">section 10 of RFC 2616</a>.</p>
-
-<h2 id="Information_responses">Information responses</h2>
-
-<dl>
- <dt>{{HTTPStatus(100, "100 Continue")}}</dt>
- <dd>This interim response indicates that everything so far is OK and that the client should continue with the request or ignore it if it is already finished.</dd>
- <dt>{{HTTPStatus(101, "101 Switching Protocol")}}</dt>
- <dd>This code is sent in response to an {{HTTPHeader("Upgrade")}} request header by the client, and indicates the protocol the server is switching too.</dd>
- <dt>{{HTTPStatus(102, "102 Processing")}} ({{Glossary("WebDAV")}})</dt>
- <dd>This code indicates that the server has received and is processing the request, but no response is available yet.</dd>
-</dl>
-
-<h2 id="Successful_responses">Successful responses</h2>
-
-<dl>
- <dt>{{HTTPStatus(200, "200 OK")}}</dt>
- <dd>The request has succeeded. The meaning of a success varies depending on the HTTP method:<br>
- GET: The resource has been fetched and is transmitted in the message body.<br>
- HEAD: The entity headers are in the message body.<br>
- POST: The resource describing the result of the action is transmitted in the message body.<br>
- TRACE: The message body contains the request message as received by the server</dd>
- <dt>{{HTTPStatus(201, "201 Created")}}</dt>
- <dd>The request has succeeded and a new resource has been created as a result of it. This is typically the response sent after a PUT request.</dd>
- <dt>{{HTTPStatus(202, "202 Accepted")}}</dt>
- <dd>The request has been received but not yet acted upon. It is non-committal, meaning that there is no way in 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.</dd>
- <dt>{{HTTPStatus(203, "203 Non-Authoritative Information")}}</dt>
- <dd>This response code means returned meta-information set is not exact set as available from the origin server, but collected from a local or a third party copy. Except this condition, 200 OK response should be preferred instead of this response.</dd>
- <dt>{{HTTPStatus(204, "204 No Content")}}</dt>
- <dd>There is no content to send for this request, but the headers may be useful. The user-agent may update its cached headers for this resource with the new ones.</dd>
- <dt>{{HTTPStatus(205, "205 Reset Content")}}</dt>
- <dd>This response code is sent after accomplishing request to tell user agent reset document view which sent this request.</dd>
- <dt>{{HTTPStatus(206, "206 Partial Content")}}</dt>
- <dd>This response code is used because of range header sent by the client to separate download into multiple streams.</dd>
- <dt>{{HTTPStatus(207, "207 Multi-Status")}} ({{Glossary("WebDAV")}})</dt>
- <dd>A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate.</dd>
- <dt>{{HTTPStatus(208, "208 Multi-Status")}} ({{Glossary("WebDAV")}})</dt>
- <dd>Used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly.</dd>
- <dt>{{HTTPStatus(226, "226 IM Used")}} (<a href="https://tools.ietf.org/html/rfc3229">HTTP Delta encoding</a>)</dt>
- <dd>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.</dd>
-</dl>
-
-<h2 id="Redirection_messages">Redirection messages</h2>
-
-<dl>
- <dt>{{HTTPStatus(300, "300 Multiple Choice")}}</dt>
- <dd>The request has more than one possible responses. User-agent or user should choose one of them. There is no standardized way to choose one of the responses.</dd>
- <dt>{{HTTPStatus(301, "301 Moved Permanently")}}</dt>
- <dd>This response code means that URI of requested resource has been changed. Probably, new URI would be given in the response.</dd>
- <dt>{{HTTPStatus(302, "302 Found")}}</dt>
- <dd>This response code means that URI of requested resource has been changed <em>temporarily</em>. New changes in the URI might be made in the future. Therefore, this same URI should be used by the client in future requests.</dd>
- <dt>{{HTTPStatus(303, "303 See Other")}}</dt>
- <dd>Server sent this response to directing client to get requested resource to another URI with an GET request.</dd>
- <dt>{{HTTPStatus(304, "304 Not Modified")}}</dt>
- <dd>This is used for caching purposes. It is telling to client that response has not been modified. So, client can continue to use same cached version of response.</dd>
- <dt><code>305 Use Proxy</code> {{deprecated_inline}}</dt>
- <dd>Was 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.</dd>
- <dt><code>306 unused</code></dt>
- <dd>This response code is no longer used, it is just reserved currently. It was used in a previous version of the HTTP 1.1 specification.</dd>
- <dt>{{HTTPStatus(307, "307 Temporary Redirect")}}</dt>
- <dd>Server sent this response to directing client to get requested resource to another URI with same method that used prior request. This has the same semantic than the <code>302 Found</code> HTTP response code, with the exception that the user agent <em>must not</em> change the HTTP method used: if a <code>POST</code> was used in the first request, a <code>POST</code> must be used in the second request.</dd>
- <dt>{{HTTPStatus(308, "308 Permanent Redirect")}}</dt>
- <dd>This means that the resource is now permanently located at another URI, specified by the <code>Location:</code> HTTP Response header. This has the same semantics as the <code>301 Moved Permanently</code> HTTP response code, with the exception that the user agent <em>must not</em> change the HTTP method used: if a <code>POST</code> was used in the first request, a <code>POST</code> must be used in the second request.</dd>
-</dl>
-
-<h2 id="Client_error_responses">Client error responses</h2>
-
-<dl>
- <dt>{{HTTPStatus(400, "400 Bad Request")}}</dt>
- <dd>This response means that server could not understand the request due to invalid syntax.</dd>
- <dt>{{HTTPStatus(401, "401 Unauthorized")}}</dt>
- <dd>Although the HTTP standard specifies "unauthorized", semantically this response means "unauthenticated". That is, the client must authenticate itself to get the requested response.</dd>
- <dt><code>402 Payment Required</code></dt>
- <dd>This response code is reserved for future use. Initial aim for creating this code was using it for digital payment systems however this is not used currently.</dd>
- <dt>{{HTTPStatus(403, "403 Forbidden")}}</dt>
- <dd>The client does not have access rights to the content, i.e. they are unauthorized, so server is rejecting to give proper response. Unlike 401, the client's identity is known to the server.</dd>
- <dt>{{HTTPStatus(404, "404 Not Found")}}</dt>
- <dd>The server can not find requested resource. In the browser, this means the URL is not recognized. In an API, this can also mean that the endpoint is valid but the resource itself does not exist. Servers may also send this response instead of 403 to hide the existence of a resource from an unauthorized client. This response code is probably the most famous one due to its frequent occurence on the web.</dd>
- <dt>{{HTTPStatus(405, "405 Method Not Allowed")}}</dt>
- <dd>The request method is known by the server but has been disabled and cannot be used. For example, an API may forbid DELETE-ing a resource. The two mandatory methods, <code>GET</code> and <code>HEAD</code>, must never be disabled and should not return this error code.</dd>
- <dt>{{HTTPStatus(406, "406 Not Acceptable")}}</dt>
- <dd>This response is sent when the web server, after performing <a href="/en-US/docs/HTTP/Content_negotiation#Server-driven_negotiation">server-driven content negotiation</a>, doesn't find any content following the criteria given by the user agent.</dd>
- <dt>{{HTTPStatus(407, "407 Proxy Authentication Required")}}</dt>
- <dd>This is similar to 401 but authentication is needed to be done by a proxy.</dd>
- <dt>{{HTTPStatus(408, "408 Request Timeout")}}</dt>
- <dd>This response is sent on an idle connection by some servers, even without any previous request by the client. It means that the server would like to shut down this unused connection. This response is used much more since some browsers, like Chrome, Firefox 27+, or IE9, use HTTP pre-connection mechanisms to speed up surfing. Also note that some servers merely shut down the connection without sending this message.</dd>
- <dt>{{HTTPStatus(409, "409 Conflict")}}</dt>
- <dd>This response is sent when a request conflicts with the current state of the server.</dd>
- <dt>{{HTTPStatus(410, "410 Gone")}}</dt>
- <dd>This response would be sent when the requested content has been permenantly deleted from server, with no forwarding address. Clients are expected to remove their caches and links to the resource. The HTTP specification intends this status code to be used for "limited-time, promotional services". APIs should not feel compelled to indicate resources that have been deleted with this status code.</dd>
- <dt>{{HTTPStatus(411, "411 Length Required")}}</dt>
- <dd>Server rejected the request because the <code>Content-Length</code> header field is not defined and the server requires it.</dd>
- <dt>{{HTTPStatus(412, "412 Precondition Failed")}}</dt>
- <dd>The client has indicated preconditions in its headers which the server does not meet.</dd>
- <dt>{{HTTPStatus(413, "413 Payload Too Large")}}</dt>
- <dd>Request entity is larger than limits defined by server; the server might close the connection or return an <code>Retry-After</code> header field.</dd>
- <dt>{{HTTPStatus(414, "414 URI Too Long")}}</dt>
- <dd>The URI requested by the client is longer than the server is willing to interpret.</dd>
- <dt>{{HTTPStatus(415, "415 Unsupported Media Type")}}</dt>
- <dd>The media format of the requested data is not supported by the server, so the server is rejecting the request.</dd>
- <dt>{{HTTPStatus(416, "416 Requested Range Not Satisfiable")}}</dt>
- <dd>The range specified by the <code>Range</code> header field in the request can't be fulfilled; it's possible that the range is outside the size of the target URI's data.</dd>
- <dt>{{HTTPStatus(417, "417 Expectation Failed")}}</dt>
- <dd>This response code means the expectation indicated by the <code>Expect</code> request header field can't be met by the server.</dd>
- <dt>{{HTTPStatus(418, "418 I'm a teapot")}}</dt>
- <dd>The server refuses the attempt to brew coffee with a teapot.</dd>
- <dt>{{HTTPStatus(421, "421 Misdirected Request")}}</dt>
- <dd>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.</dd>
- <dt>{{HTTPStatus(422, "422 Unprocessable Entity")}} ({{Glossary("WebDAV")}})</dt>
- <dd>The request was well-formed but was unable to be followed due to semantic errors.</dd>
- <dt>{{HTTPStatus(423, "423 Locked")}} ({{Glossary("WebDAV")}})</dt>
- <dd>The resource that is being accessed is locked.</dd>
- <dt>{{HTTPStatus(424, "424 Failed Dependency")}} ({{Glossary("WebDAV")}})</dt>
- <dd>The request failed due to failure of a previous request.</dd>
- <dt>{{HTTPStatus(426, "426 Upgrade Required")}}</dt>
- <dd>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. The server sends an {{HTTPHeader("Upgrade")}} header in a 426 response to indicate the required protocol(s).</dd>
- <dt>{{HTTPStatus(428, "428 Precondition Required")}}</dt>
- <dd>The origin server requires the request to be conditional. Intended to prevent the 'lost update' problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.</dd>
- <dt>{{HTTPStatus(429, "429 Too Many Requests")}}</dt>
- <dd>The user has sent too many requests in a given amount of time ("rate limiting").</dd>
- <dt>{{HTTPStatus(431, "431 Request Header Fields Too Large")}}</dt>
- <dd>The server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields.</dd>
- <dt>{{HTTPStatus(451, "451 Unavailable For Legal Reasons")}}</dt>
- <dd>The user requests an illegal resource, such as a web page censored by a government.</dd>
-</dl>
-
-<h2 id="Server_error_responses">Server error responses</h2>
-
-<dl>
- <dt>{{HTTPStatus(500, "500 Internal Server Error")}}</dt>
- <dd>The server has encountered a situation it doesn't know how to handle.</dd>
- <dt>{{HTTPStatus(501, "501 Not Implemented")}}</dt>
- <dd>The request method is not supported by the server and cannot be handled. The only methods that servers are required to support (and therefore that must not return this code) are <code>GET</code> and <code>HEAD</code>.</dd>
- <dt>{{HTTPStatus(502, "502 Bad Gateway")}}</dt>
- <dd>This error response means that the server, while working as a gateway to get a response needed to handle the request, got an invalid response.</dd>
- <dt>{{HTTPStatus(503, "503 Service Unavailable")}}</dt>
- <dd>The server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded. Note that together with this response, a user-friendly page explaining the problem should be sent. This responses should be used for temporary conditions and the <code>Retry-After:</code> HTTP header should, if possible, contain the estimated time before the recovery of the service. The webmaster must also take care about the caching-related headers that are sent along with this response, as these temporary condition responses should usually not be cached.</dd>
- <dt>{{HTTPStatus(504, "504 Gateway Timeout")}}</dt>
- <dd>This error response is given when the server is acting as a gateway and cannot get a response in time.</dd>
- <dt>{{HTTPStatus(505, "505 HTTP Version Not Supported")}}</dt>
- <dd>The HTTP version used in the request is not supported by the server.</dd>
- <dt>{{HTTPStatus(506, "506 Variant Also Negotiates")}}</dt>
- <dd>The server has an internal configuration error: transparent content negotiation for the request results in a circular reference.</dd>
- <dt>{{HTTPStatus(507, "507 Insufficient Storage")}}</dt>
- <dd>The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.</dd>
- <dt>{{HTTPStatus(508, "508 Loop Detected")}} ({{Glossary("WebDAV")}})</dt>
- <dd>The server detected an infinite loop while processing the request.</dd>
- <dt>{{HTTPStatus(510, "510 Not Extended")}}</dt>
- <dd>Further extensions to the request are required for the server to fulfill it.</dd>
- <dt>{{HTTPStatus(511, "511 Network Authentication Required")}}</dt>
- <dd>The 511 status code indicates that the client needs to authenticate to gain network access.</dd>
-</dl>
-
-<h2 id="See_also">See also</h2>
-
-<ul>
- <li><a href="https://en.wikipedia.org/wiki/List_of_HTTP_status_codes">List of HTTP status codes on Wikipedia</a></li>
- <li><a href="http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml">IANA official registry of HTTP status codes</a></li>
-</ul>