From 074785cea106179cb3305637055ab0a009ca74f2 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:42:52 -0500 Subject: initial commit --- .../http/cors/errors/corsdidnotsucceed/index.html | 30 ++ .../corsmissingallowheaderfrompreflight/index.html | 40 ++ files/nl/web/http/cors/errors/index.html | 76 +++ files/nl/web/http/cors/index.html | 567 +++++++++++++++++++++ files/nl/web/http/headers/index.html | 370 ++++++++++++++ files/nl/web/http/headers/location/index.html | 76 +++ .../http/headers/x-content-type-options/index.html | 84 +++ files/nl/web/http/index.html | 87 ++++ files/nl/web/http/status/100/index.html | 48 ++ files/nl/web/http/status/200/index.html | 50 ++ files/nl/web/http/status/301/index.html | 47 ++ files/nl/web/http/status/index.html | 171 +++++++ 12 files changed, 1646 insertions(+) create mode 100644 files/nl/web/http/cors/errors/corsdidnotsucceed/index.html create mode 100644 files/nl/web/http/cors/errors/corsmissingallowheaderfrompreflight/index.html create mode 100644 files/nl/web/http/cors/errors/index.html create mode 100644 files/nl/web/http/cors/index.html create mode 100644 files/nl/web/http/headers/index.html create mode 100644 files/nl/web/http/headers/location/index.html create mode 100644 files/nl/web/http/headers/x-content-type-options/index.html create mode 100644 files/nl/web/http/index.html create mode 100644 files/nl/web/http/status/100/index.html create mode 100644 files/nl/web/http/status/200/index.html create mode 100644 files/nl/web/http/status/301/index.html create mode 100644 files/nl/web/http/status/index.html (limited to 'files/nl/web/http') diff --git a/files/nl/web/http/cors/errors/corsdidnotsucceed/index.html b/files/nl/web/http/cors/errors/corsdidnotsucceed/index.html new file mode 100644 index 0000000000..111d7df5d5 --- /dev/null +++ b/files/nl/web/http/cors/errors/corsdidnotsucceed/index.html @@ -0,0 +1,30 @@ +--- +title: 'Reason: CORS request did not succeed' +slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed +tags: + - Beveiliging + - CORS + - Cross-Origin-aanvraag + - Foutmelding + - HTTP + - HTTPS + - console +translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed +--- +
{{HTTPSidebar}}
+ +

Reden

+ +
Reason: CORS request did not succeed
+ +

Wat gaat er fout?

+ +

Het {{Glossary("HTTP")}} request welke gebruik maakt van CORS faalt doordat de HTTP connectie is mislukt op het netwerk of protocol niveau. De error is niet direct te relateren aan de CORS, maar is een fundamentele netwerkfout.

+ +

Zie ook

+ + diff --git a/files/nl/web/http/cors/errors/corsmissingallowheaderfrompreflight/index.html b/files/nl/web/http/cors/errors/corsmissingallowheaderfrompreflight/index.html new file mode 100644 index 0000000000..8c29bdd056 --- /dev/null +++ b/files/nl/web/http/cors/errors/corsmissingallowheaderfrompreflight/index.html @@ -0,0 +1,40 @@ +--- +title: >- + Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from + CORS preflight channel +slug: Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight +tags: + - CORS + - CORSMissingAllowHeaderFromPreflight + - Cross-Origin + - Error + - Fout + - HTTP + - HTTPS + - Reasons + - Redenen + - Security + - console + - troubleshooting +translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight +--- +
{{HTTPSidebar}}
+ +

Reden

+ +
Reden: Het token ‘xyz’ mist in de CORS header ‘Access-Control-Allow-Headers’ van de CORS preflight channel
+ +

Wat ging er mis?

+ +

De Access-Control-Allow-Headers header is gestuurd door de server om de client te laten weten welke headers worden ondersteund voor {{Glossary("CORS")}} verzoeken. De waarde van Access-Control-Allow-Headers zou een met komma-afgebakende lijst zijn met header namen, zoals bijvoorbeeld "X-Custom-Information" of elke andere standaard, maar niet een basic header name (deze worden namelijk altijd toegestaan).

+ +

Als de {{Glossary("user agent")}} niet een waarde kan detecteren speciaal voor deze header - ook al zit deze header wel in de reponse - onstaat deze error.

+ +

Bekijk ook

+ + diff --git a/files/nl/web/http/cors/errors/index.html b/files/nl/web/http/cors/errors/index.html new file mode 100644 index 0000000000..d1dd12dc75 --- /dev/null +++ b/files/nl/web/http/cors/errors/index.html @@ -0,0 +1,76 @@ +--- +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 +--- +
{{HTTPSidebar}}
+ +

Cross-Origin Resource Sharing ({{Glossary("CORS")}}) is a standard that allows a server to relax the same-origin policy. This is used to explicitly allow some cross-origin requests while rejecting others. 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.

+ +

If the CORS configuration isn't setup correctly, the browser console will present an error like "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite" 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.

+ +

Identifying the issue

+ +

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:

+ +
    +
  1. Navigate to the web site or web app in question and open the Developer Tools.
    2. +
  2. Now try to reproduce the failing transaction and check the console if you are seeing a CORS violation error message. It will probably look like this:
    3. +
+ +

Firefox console showing CORS error

+ +

The text of the error message will be something similar to the following:

+ +
Cross-Origin Request Blocked: The Same Origin Policy disallows
+reading the remote resource at https://some-url-here. (Reason:
+additional information here).
+ +
+

Note: For security reasons, specifics about what went wrong with a CORS request are not available to JavaScript code. 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.

+
+ +

CORS error messages

+ +

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.

+ + + +

See also

+ + diff --git a/files/nl/web/http/cors/index.html b/files/nl/web/http/cors/index.html new file mode 100644 index 0000000000..463a0011bf --- /dev/null +++ b/files/nl/web/http/cors/index.html @@ -0,0 +1,567 @@ +--- +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 +--- +
{{HTTPSidebar}}
+ +

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. A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin.

+ +

An example of a cross-origin request: The frontend JavaScript code for a web application served from http://domain-a.com uses {{domxref("XMLHttpRequest")}} to make a request for http://api.domain-b.com/data.json.

+ +

For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest and the Fetch API follow the same-origin policy. This means that a web application using those APIs can only request HTTP resources from the same origin the application was loaded from, unless the response from the other origin includes the right CORS headers.

+ +

+ +

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 XMLHttpRequest or Fetch to help mitigate the risks of cross-origin HTTP requests.

+ +

Who should read this article?

+ +

Everyone, really.

+ +

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 cross-origin sharing from a server perspective (with PHP code snippets) is supplementary reading.

+ +

What requests use CORS?

+ +

This cross-origin sharing standard is used to enable cross-site HTTP requests for:

+ + + +

This article is a general discussion of Cross-Origin Resource Sharing and includes a discussion of the necessary HTTP headers.

+ +

Functional overview

+ +

The Cross-Origin Resource Sharing standard works by adding new HTTP headers 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 MIME types), 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 Cookies and HTTP Authentication data) should be sent with requests.

+ +

CORS failures result in errors, but for security reasons, specifics about what went wrong are not available to JavaScript code. 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.

+ +

Subsequent sections discuss scenarios, as well as provide a breakdown of the HTTP headers used.

+ +

Examples of access control scenarios

+ +

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.

+ +

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 http://arunranga.com/examples/access-control/, and will work in browsers that support cross-site XMLHttpRequest.

+ +

A discussion of Cross-Origin Resource Sharing from a server perspective (including PHP code snippets) can be found in the Server-Side Access Control (CORS) article.

+ +

Simple requests

+ +

Some requests don’t trigger a CORS preflight. 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 CORS preflight—a so-called “simple request” — is one that meets all the following conditions:

+ + + +
Note: 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.
+ +
Note: 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: Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS, and Switch to a blacklist model for restricted Accept headers in simple CORS requests. No other browsers implement those extra restrictions, because they’re not part of the spec.
+ +

For example, suppose web content on domain http://foo.example wishes to invoke content on domain http://bar.other. Code of this sort might be used within JavaScript deployed on foo.example:

+ +
const invocation = new XMLHttpRequest();
+const url = 'http://bar.other/resources/public-data/';
+
+function callOtherDomain() {
+  if(invocation) {
+    invocation.open('GET', url, true);
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}
+
+ +

This will lead to a simple exchange between the client and the server, using CORS headers to handle the privileges:

+ +

+ +

Let us look at what the browser will send to the server in this case, and let's see how the server responds:

+ +
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]
+
+ +

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 http://foo.example.

+ +

Lines 13 - 22 show the HTTP response from the server on domain http://bar.other. 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 Access-Control-Allow-Origin: * which means that the resource can be accessed by any domain in a cross-site manner. If the resource owners at http://bar.other wished to restrict access to the resource to requests only from http://foo.example, they would send back:

+ +

Access-Control-Allow-Origin: http://foo.example

+ +

Note that now, no domain other than http://foo.example (identified by the ORIGIN: header in the request, as in line 10 above) can access the resource in a cross-site manner. The Access-Control-Allow-Origin header should contain the value that was sent in the request's Origin header.

+ +

Preflighted requests

+ +

Unlike “simple requests” (discussed above), "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.

+ +

In particular, a request is preflighted if any of the following conditions is true:

+ + + +
Note: 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: Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS, and Switch to a blacklist model for restricted Accept headers in simple CORS requests. No other browsers implement those extra restrictions, because they’re not part of the spec.
+ +

The following is an example of a request that will be preflighted.

+ +
const invocation = new XMLHttpRequest();
+const url = 'http://bar.other/resources/post-here/';
+const body = '<?xml version="1.0"?><person><name>Arun</name></person>';
+
+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);
+    }
+}
+
+......
+
+ +

In the example above, line 3 creates an XML body to send with the POST request in line 8. Also, on line 9, a "customized" (non-standard) HTTP request header is set (X-PINGOTHER: pingpong). 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 application/xml, and since a custom header is set, this request is preflighted.

+ +

+ +

(Note: as described below, the actual POST request does not include the Access-Control-Request-* headers; they are needed only for the OPTIONS request.)

+ +

Let's take a look at the full exchange between client and server. The first exchange is the preflight request/response:

+ +
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 204 No Content
+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
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+
+ +

Once the preflight request is complete, the real request is sent:

+ +
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
+
+<?xml version="1.0"?><person><name>Arun</name></person>
+
+
+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]
+
+ +

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):

+ +
Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+
+ +

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 POST 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 X-PINGOTHER and Content-Type custom headers. The server now has an opportunity to determine whether it wishes to accept a request under these circumstances.

+ +

Lines 14 - 26 above are the response that the server sends back indicating that the request method (POST) and request headers (X-PINGOTHER) are acceptable. In particular, let's look at lines 17-20:

+ +
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
+ +

The server responds with Access-Control-Allow-Methods and says that POST and GET 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.

+ +

The server also sends Access-Control-Allow-Headers with a value of "X-PINGOTHER, Content-Type", confirming that these are permitted headers to be used with the actual request. Like Access-Control-Allow-Methods, Access-Control-Allow-Headers is a comma separated list of acceptable headers.

+ +

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 maximum internal value that takes precedence when the Access-Control-Max-Age is greater.

+ +

Preflighted requests and redirects

+ +

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.

+ +
+

The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight

+
+ +
+

Request requires preflight, which is disallowed to follow cross-origin redirect

+
+ +

The CORS protocol originally required that behavior but was subsequently changed to no longer require it. However, not all browsers have implemented the change, and so still exhibit the behavior that was originally required.

+ +

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:

+ + + +

But if it’s not possible to make those changes, then another way that may be possible is to this:

+ +
    +
  1. Make a simple request (using {{domxref("Response.url")}} for the Fetch API, or {{domxref("XMLHttpRequest.responseURL")}}) to determine what URL the real preflighted request would end up at.
    2. +
  2. Make another request (the “real” request) using the URL you obtained from Response.url or XMLHttpRequest.responseURL in the first step.
    3. +
+ +

However, if the request is one that triggers a preflight due to the presence of the Authorization 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.

+ +

Requests with credentials

+ +

The most interesting capability exposed by both {{domxref("XMLHttpRequest")}} or Fetch and CORS is the ability to make "credentialed" requests that are aware of HTTP cookies and HTTP Authentication information. By default, in cross-site XMLHttpRequest or Fetch invocations, browsers will not send credentials. A specific flag has to be set on the XMLHttpRequest object or the {{domxref("Request")}} constructor when it is invoked.

+ +

In this example, content originally loaded from http://foo.example makes a simple GET request to a resource on http://bar.other which sets Cookies. Content on foo.example might contain JavaScript like this:

+ +
const invocation = new XMLHttpRequest();
+const url = 'http://bar.other/resources/credentialed-content/';
+
+function callOtherDomain(){
+  if(invocation) {
+    invocation.open('GET', url, true);
+    invocation.withCredentials = true;
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}
+ +

Line 7 shows the flag on {{domxref("XMLHttpRequest")}} that has to be set in order to make the invocation with Cookies, namely the withCredentials boolean value. By default, the invocation is made without Cookies. Since this is a simple GET request, it is not preflighted, but the browser will reject any response that does not have the {{HTTPHeader("Access-Control-Allow-Credentials")}}: true header, and not make the response available to the invoking web content.

+ +

+ +

Here is a sample exchange between client and server:

+ +
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]
+
+ +

Although line 11 contains the Cookie destined for the content on http://bar.other, if bar.other did not respond with an {{HTTPHeader("Access-Control-Allow-Credentials")}}: true (line 19) the response would be ignored and not made available to web content.

+ +

Credentialed requests and wildcards

+ +

When responding to a credentialed request, the server must specify an origin in the value of the Access-Control-Allow-Origin header, instead of specifying the "*" wildcard.

+ +

Because the request headers in the above example include a Cookie header, the request would fail if the value of the Access-Control-Allow-Origin header were "*". But it does not fail: Because the value of the Access-Control-Allow-Origin header is "http://foo.example" (an actual origin) rather than the "*" wildcard, the credential-cognizant content is returned to the invoking web content.

+ +

Note that the Set-Cookie response header in the example above also sets a further cookie. In case of failure, an exception—depending on the API used—is raised.

+ +

Third-party cookies

+ +

Note that cookies set in CORS responses are subject to normal third-party cookie policies. In the example above, the page is loaded from foo.example, but the cookie on line 22 is sent by bar.other, and would thus not be saved if the user has configured their browser to reject all third-party cookies.

+ +

The HTTP response headers

+ +

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.

+ +

Access-Control-Allow-Origin

+ +

A returned resource may have one {{HTTPHeader("Access-Control-Allow-Origin")}} header, with the following syntax:

+ +
Access-Control-Allow-Origin: <origin> | *
+
+ +

Access-Control-Allow-Origin specifies either a single origin, which tells browsers to allow that origin to access the resource; or else — for requests without credentials — the "*" wildcard, to tell browsers to allow any origin to access the resource.

+ +

For example, to allow code from the origin http://mozilla.org to access the resource, you can specify:

+ +
Access-Control-Allow-Origin: http://mozilla.org
+ +

If the server specifies a single origin rather than the "*" wildcard, then the server should also include Origin 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.

+ +

Access-Control-Expose-Headers

+ +

The {{HTTPHeader("Access-Control-Expose-Headers")}} header lets a server whitelist headers that browsers are allowed to access.

+ +
Access-Control-Expose-Headers: <field-name>[, <field-name>]*
+
+ +

For example, the following:

+ +
Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
+
+ +

…would allow the X-My-Custom-Header and X-Another-Custom-Header headers to be exposed to the browser.

+ +

Access-Control-Max-Age

+ +

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.

+ +
Access-Control-Max-Age: <delta-seconds>
+
+ +

The delta-seconds parameter indicates the number of seconds the results can be cached.

+ +

Access-Control-Allow-Credentials

+ +

The {{HTTPHeader("Access-Control-Allow-Credentials")}} header Indicates whether or not the response to the request can be exposed when the credentials 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 GET requests are not preflighted, and so if a request is made for a resource with credentials, if this header is not returned with the resource, the response is ignored by the browser and not returned to web content.

+ +
Access-Control-Allow-Credentials: true
+
+ +

Credentialed requests are discussed above.

+ +

Access-Control-Allow-Methods

+ +

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.

+ +
Access-Control-Allow-Methods: <method>[, <method>]*
+
+ +

An example of a preflight request is given above, including an example which sends this header to the browser.

+ +

Access-Control-Allow-Headers

+ +

The {{HTTPHeader("Access-Control-Allow-Headers")}} header is used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.

+ +
Access-Control-Allow-Headers: <field-name>[, <field-name>]*
+
+ +

The HTTP request headers

+ +

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.

+ +

Origin

+ +

The {{HTTPHeader("Origin")}} header indicates the origin of the cross-site access request or preflight request.

+ +
Origin: <origin>
+
+ +

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.

+ +
Note: The origin value can be null, or a URI.
+ +

Note that in any access control request, the {{HTTPHeader("Origin")}} header is always sent.

+ +

Access-Control-Request-Method

+ +

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.

+ +
Access-Control-Request-Method: <method>
+
+ +

Examples of this usage can be found above.

+ +

Access-Control-Request-Headers

+ +

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.

+ +
Access-Control-Request-Headers: <field-name>[, <field-name>]*
+
+ +

Examples of this usage can be found above.

+ +

Specifications

+ + + + + + + + + + + + + + +
SpecificationStatusComment
{{SpecName('Fetch', '#cors-protocol', 'CORS')}}{{Spec2('Fetch')}}New definition; supplants W3C CORS specification.
+ +

Browser compatibility

+ + + +

{{Compat("http.headers.Access-Control-Allow-Origin")}}

+ +

Compatibility notes

+ + + +

See also

+ + diff --git a/files/nl/web/http/headers/index.html b/files/nl/web/http/headers/index.html new file mode 100644 index 0000000000..b6923ef46d --- /dev/null +++ b/files/nl/web/http/headers/index.html @@ -0,0 +1,370 @@ +--- +title: HTTP headers +slug: Web/HTTP/Headers +tags: + - HTTP + - Headers + - NeedsTranslation + - Networking + - Reference + - TopicStub +translation_of: Web/HTTP/Headers +--- +
{{HTTPSidebar}}
+ +

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 line breaks). Leading white space before the value is ignored.

+ +

Custom proprietary headers can be added using the 'X-' prefix, but this convention was deprecated in June 2012, because of the inconveniences it caused when non-standard fields became standard in RFC 6648; others are listed in an IANA registry, whose original content was defined in RFC 4229. IANA also maintains a registry of proposed new HTTP message headers.

+ +

Headers can be grouped according to their contexts:

+ + + +

Headers can also be grouped according to how proxies handle them:

+ +
+
End-to-end headers
+
These headers must be transmitted to the final recipient of the message; that is, the server for a request or the client for a response. Intermediate proxies must retransmit end-to-end headers unmodified and caches must store them.
+
Hop-by-hop headers
+
These headers are meaningful only for a single transport-level connection and must not be retransmitted by proxies or cached. Such headers are: {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }} and {{ httpheader("Upgrade") }}. Note that only hop-by-hop headers may be set using the {{ httpheader("Connection") }} general header.
+
+ +

The following list summarizes HTTP headers by their usage category. For an alphabetical list, see the navigation on the left side.

+ +

Authentication

+ +
+
{{HTTPHeader("WWW-Authenticate")}}
+
Defines the authentication method that should be used to gain access to a resource.
+
{{HTTPHeader("Authorization")}}
+
Contains the credentials to authenticate a user agent with a server.
+
{{HTTPHeader("Proxy-Authenticate")}}
+
Defines the authentication method that should be used to gain access to a resource behind a Proxy server.
+
{{HTTPHeader("Proxy-Authorization")}}
+
Contains the credentials to authenticate a user agent with a proxy server.
+
+ +

Caching

+ +
+
{{HTTPHeader("Age")}}
+
The time in seconds the object has been in a proxy cache.
+
{{HTTPHeader("Cache-Control")}}
+
Specifies directives for caching mechanisms in both requests and responses.
+
{{HTTPHeader("Expires")}}
+
The date/time after which the response is considered stale.
+
{{HTTPHeader("Pragma")}}
+
Implementation-specific header that may have various effects anywhere along the request-response chain. Used for backwards compatibility with HTTP/1.0 caches where the Cache-Control header is not yet present.
+
{{HTTPHeader("Warning")}}
+
A general warning field containing information about possible problems.
+
+ +

Client hints

+ +
+
{{HTTPHeader("Accept-CH")}}
+
...
+
{{HTTPHeader("Content-DPR")}}
+
...
+
{{HTTPHeader("DPR")}}
+
...
+
{{HTTPHeader("Downlink")}}
+
...
+
{{HTTPHeader("Save-Data")}}
+
...
+
{{HTTPHeader("Viewport-Width")}}
+
...
+
{{HTTPHeader("Width")}}
+
...
+
+ +
+
+

Conditionals

+
+
{{HTTPHeader("Last-Modified")}}
+
It is a validator, 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.
+
{{HTTPHeader("ETag")}}
+
It is a validator, 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.
+
{{HTTPHeader("If-Match")}}
+
Makes the request conditional and applies the method only if the stored resource matches one of the given ETags.
+
{{HTTPHeader("If-None-Match")}}
+
Makes the request conditional and applies the method only if the stored resource doesn't match any of the given ETags. This is used to update caches (for safe requests), or to prevent to upload a new resource when one is already existing.
+
{{HTTPHeader("If-Modified-Since")}}
+
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.
+
{{HTTPHeader("If-Unmodified-Since")}}
+
Makes the request conditional and expects the entity to be transmitted only if it has not been modified after the given date. This is used to ensure 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.
+
+ +

Connection management

+ +
+
{{HTTPHeader("Connection")}}
+
Controls whether the network connection stays open after the current transaction finishes.
+
{{HTTPHeader("Keep-Alive")}}
+
Controls how long a persistent connection should stay open.
+
+ +

Content negotiation

+ +
+
{{HTTPHeader("Accept")}}
+
Informs the server about the types of data that can be sent back. It is MIME-type.
+
{{HTTPHeader("Accept-Charset")}}
+
Informs the server about which character set the client is able to understand.
+
{{HTTPHeader("Accept-Encoding")}}
+
Informs the server about the encoding algorithm, usually a compression algorithm, that can be used on the resource sent back.
+
{{HTTPHeader("Accept-Language")}}
+
Informs the server about the 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 in a drop down list).
+
+ +
+
+ +

Controls

+ +
+
{{HTTPHeader("Expect")}}
+
Indicates expectations that need to be fulfilled by the server in order to properly handle the request.
+
{{HTTPHeader("Max-Forwards")}}
+
...
+
+ +

Cookies

+ +
+
{{HTTPHeader("Cookie")}}
+
Contains stored HTTP cookies previously sent by the server with the {{HTTPHeader("Set-Cookie")}} header.
+
{{HTTPHeader("Set-Cookie")}}
+
Send cookies from the server to the user agent.
+
{{HTTPHeader("Cookie2")}} {{obsolete_inline}}
+
Used to contain an HTTP cookie, previously sent by the server with the {{HTTPHeader("Set-Cookie2")}} header, but has been obsoleted by the specification. Use {{HTTPHeader("Cookie")}} instead.
+
{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}
+
Used to send cookies from the server to the user agent, but has been obsoleted by the specification. Use {{HTTPHeader("Set-Cookie")}} instead.
+
+

CORS

+
+
{{HTTPHeader("Access-Control-Allow-Origin")}}
+
Indicates whether the response can be shared.
+
{{HTTPHeader("Access-Control-Allow-Credentials")}}
+
Indicates whether the response to the request can be exposed when the credentials flag is true.
+
{{HTTPHeader("Access-Control-Allow-Headers")}}
+
Used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.
+
{{HTTPHeader("Access-Control-Allow-Methods")}}
+
Specifies the method or methods allowed when accessing the resource in response to a preflight request.
+
{{HTTPHeader("Access-Control-Expose-Headers")}}
+
Indicates which headers can be exposed as part of the response by listing their names.
+
{{HTTPHeader("Access-Control-Max-Age")}}
+
Indicates how long the results of a preflight request can be cached.
+
{{HTTPHeader("Access-Control-Request-Headers")}}
+
Used when issuing a preflight request to let the server know which HTTP headers will be used when the actual request is made.
+
{{HTTPHeader("Access-Control-Request-Method")}}
+
Used when issuing a preflight request to let the server know which HTTP method will be used when the actual request is made.
+
{{HTTPHeader("Origin")}}
+
Indicates where a fetch originates from.
+
{{HTTPHeader("Timing-Allow-Origin")}}
+
Specifies origins that are allowed to see values of attributes retrieved via features of the Resource Timing API, which would otherwise be reported as zero due to cross-origin restrictions.
+
+ +

Do Not Track

+ +
+
{{HTTPHeader("DNT")}}
+
Used for expressing the user's tracking preference.
+
{{HTTPHeader("Tk")}}
+
Indicates the tracking status that applied to the corresponding request.
+
+ +

Downloads

+ +
+
{{HTTPHeader("Content-Disposition")}}
+
Is a response header if the resource transmitted should be displayed inline (default behavior when the header is not present), or it should be handled like a download and the browser should present a 'Save As' window.
+
+ +

Message body information

+ +
+
{{HTTPHeader("Content-Length")}}
+
indicates the size of the entity-body, in decimal number of octets, sent to the recipient.
+
{{HTTPHeader("Content-Type")}}
+
Indicates the media type of the resource.
+
{{HTTPHeader("Content-Encoding")}}
+
Used to specify the compression algorithm.
+
{{HTTPHeader("Content-Language")}}
+
Describes the language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.
+
{{HTTPHeader("Content-Location")}}
+
Indicates an alternate location for the returned data.
+
+

Proxies

+
+
+ +
+
{{HTTPHeader("Forwarded")}}
+
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.
+
{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}
+
Identifies the originating IP addresses of a client connecting to a web server through an HTTP proxy or a load balancer.
+
{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}
+
Identifies the original host requested that a client used to connect to your proxy or load balancer.
+
{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}
+
identifies the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.
+
{{HTTPHeader("Via")}}
+
Added by proxies, both forward and reverse proxies, and can appear in the request headers and the response headers.
+
+ +

Redirects

+ +
+
{{HTTPHeader("Location")}}
+
Indicates the URL to redirect a page to.
+
+ +

Request context

+ +
+
{{HTTPHeader("From")}}
+
Contains an Internet email address for a human user who controls the requesting user agent.
+
{{HTTPHeader("Host")}}
+
Specifies the domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening.
+
{{HTTPHeader("Referer")}}
+
The address of the previous web page from which a link to the currently requested page was followed.
+
{{HTTPHeader("Referrer-Policy")}}
+
Governs which referrer information sent in the {{HTTPHeader("Referer")}} header should be included with requests made.
+
{{HTTPHeader("User-Agent")}}
+
Contains a characteristic string that allows the network protocol peers to identify the application type, operating system, software vendor or software version of the requesting software user agent. See also the Firefox user agent string reference.
+
+ +

Response context

+ +
+
{{HTTPHeader("Allow")}}
+
Lists the set of HTTP request methods support by a resource.
+
{{HTTPHeader("Server")}}
+
Contains information about the software used by the origin server to handle the request.
+
+ +

Range requests

+ +
+
{{HTTPHeader("Accept-Ranges")}}
+
Indicates if the server supports range requests and if so, in which unit the range can be expressed.
+
{{HTTPHeader("Range")}}
+
Indicates the part of a document that the server should return.
+
{{HTTPHeader("If-Range")}}
+
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.
+
{{HTTPHeader("Content-Range")}}
+
Indicates where in a full body message a partial message belongs.
+
+ +

Security

+ +
+
{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})
+
Controls resources the user agent is allowed to load for a given page.
+
{{HTTPHeader("Content-Security-Policy-Report-Only")}}
+
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 POST request to the specified URI.
+
{{HTTPHeader("Public-Key-Pins")}} ({{Glossary("HPKP")}})
+
Associates a specific cryptographic public key with a certain web server to decrease the risk of {{Glossary("MITM")}} attacks with forged certificates.
+
{{HTTPHeader("Public-Key-Pins-Report-Only")}}
+
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.
+
+ +
+
{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})
+
Force communication using HTTPS instead of HTTP.
+
{{HTTPHeader("Upgrade-Insecure-Requests")}}
+
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.
+
+ +
+
{{HTTPHeader("X-Content-Type-Options")}}
+
Disables MIME sniffing and forces browser to use the type given in {{HTTPHeader("Content-Type")}}.
+
+ +
+
{{HTTPHeader("X-Frame-Options")}} (XFO)
+
Indicates whether a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}} or {{HTMLElement("object")}}
+
{{HTTPHeader("X-XSS-Protection")}}
+
Enables cross-site scripting filtering.
+
+ +

Server-sent events

+ +
+
{{HTTPHeader("Ping-From")}}
+
...
+
{{HTTPHeader("Ping-To")}}
+
...
+
{{HTTPHeader("Last-Event-ID")}}
+
...
+
+ +

Transfer coding

+ +
+
{{HTTPHeader("Transfer-Encoding")}}
+
Specifies the the form of encoding used to safely transfer the entity to the user.
+
{{HTTPHeader("TE")}}
+
Specifies the transfer encodings the user agent is willing to accept.
+
{{HTTPHeader("Trailer")}}
+
Allows the sender to include additional fields at the end of chunked message.
+
+ +

WebSockets

+ +
+
{{HTTPHeader("Sec-WebSocket-Key")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Extensions")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Accept")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Protocol")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Version")}}
+
...
+
+ +

Other

+ +
+
{{HTTPHeader("Date")}}
+
Contains the date and time at which the message was originated.
+
{{HTTPHeader("Large-Allocation")}}
+
Tells the browser that the page being loaded is going to want to perform a large allocation.
+
{{HTTPHeader("Link")}}
+
...
+
{{HTTPHeader("Retry-After")}}
+
Indicates how long the user agent should wait before making a follow-up request.
+
{{HTTPHeader("SourceMap")}}
+
Links generated code to a source map.
+
{{HTTPHeader("Upgrade")}}
+
The relevant RFC document for the Upgrade header field is RFC 7230, section 6.7.  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.  Niether 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 please see section 6.1 of the aforementioned RFC.
+
{{HTTPHeader("Vary")}}
+
Determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server.
+
{{HTTPHeader("X-DNS-Prefetch-Control")}}
+
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.
+
{{HTTPHeader("X-Firefox-Spdy")}}
+
...
+
{{HTTPHeader("X-Requested-With")}}
+
...
+
{{HTTPHeader("X-UA-Compatible")}}
+
...
+
+ +

Contributing

+ +

You can help by writing new entries or improving the existing ones.

+ +

See also

+ + diff --git a/files/nl/web/http/headers/location/index.html b/files/nl/web/http/headers/location/index.html new file mode 100644 index 0000000000..f942be6693 --- /dev/null +++ b/files/nl/web/http/headers/location/index.html @@ -0,0 +1,76 @@ +--- +title: Location +slug: Web/HTTP/Headers/Location +translation_of: Web/HTTP/Headers/Location +--- +

De Location antwoord header geeft de URL aan waar naar de pagina veranderd is. Het is alleen van toepassing bij een 3xx status antwoord.

+ +

De HTTP methode die wordt gebruikt om een nieuwe aanvraag op te halen die verwezen wordt door deLocation hangt van de orginele methode en de type van omleiding af.

+ + + +

Alle antwoorden met een van deze statussen sturen een Location header.

+ +

Niet alleen een omleidings antwoord, maar ook berichten met een{{HTTPHeader("201")}} (Aangemaakt) status hebben ook eenLocation header. Het weergeeft de URL van de nieuw gemaakte hulpbron.

+ +

Location en {{HTTPHeader("Content-Location")}} zijn anders: Location geeft de bestemming aan van de omleiding (of de URL van de nieuw aangemaake hulpbron), terwijl {{HTTPHeader("Content-Location")}} de directe URL weergeeft die zou moeten worden gebruikt wanneer er een content negotiation gebeurt, zonder verdere onderhandeling. Location is een header die bij een antwoord hoort, terwijl een {{HTTPHeader("Content-Location")}} hoort bij een entity die terug verzonden is.

+ + + + + + + + + + + + +
Header type{{Glossary("Antwoord header")}}
{{Glossary("Verboden header naam")}}Nee
+ +

Syntax

+ +
Location: <url>
+
+ +

Richtlijnen

+ +
+
<url>
+
Een relatieve (naar de aanvraag) of absolute URL.
+
+ +

Voorbeelden

+ +
Location: /index.html
+ +

Specificaties

+ + + + + + + + + + + + +
SpecificatieTitel
{{RFC("7231", "Location", "7.1.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Browser ondersteuning

+ + + +

{{Compat("http.headers.Location")}}

+ +

Zie ook

+ + diff --git a/files/nl/web/http/headers/x-content-type-options/index.html b/files/nl/web/http/headers/x-content-type-options/index.html new file mode 100644 index 0000000000..bf87fc98ea --- /dev/null +++ b/files/nl/web/http/headers/x-content-type-options/index.html @@ -0,0 +1,84 @@ +--- +title: X-Content-Type-Options +slug: Web/HTTP/Headers/X-Content-Type-Options +translation_of: Web/HTTP/Headers/X-Content-Type-Options +--- +
{{HTTPSidebar}}
+ +
De X-Content-Type-Options antwoord HTTP header is een aanduiding die door de server wordt gebruikt om aan te tonen dat de MIME types die in de {{HTTPHeader("Content-Type")}} headers zijn geadverteerd, niet gewijzigd moeten worden en moeten worden gevold. Dit zorgt voor de mogelijkheid om niet deel te nemen aan MIME type sniffing, of, met andere woorden, het is een manier waarop de webmasters tonen dat ze weten wat ze deden
+ +
 
+ +
Deze header is geïntroduceerd door Microsoft in IE8 om webmasters de mogelijkheid te geven om het content sniffing te blokkeren dat toen gebeurde. De header kan niet uitvoerbare MIME types omvormen tot uitvoerbare MIME types. Andere browsers hebben dit later ook geïntroduceerd, ook al zijn hun MIME sniffing algoritmes minder agressief.
+ +
 
+ +
Site veiligheid testers verwachten dat deze header geset is.
+ +
 
+ +

Nota: nosniff wordt enkel toegepast op "script" en"style" types. Het toepassen van de nosniff op afbeeldingen bleek niet compatibel te zijn met bestaande websites.

+ + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}nee
+ +

Syntax

+ +
X-Content-Type-Options: nosniff
+
+ +

Directives

+ +
+
nosniff
+
Blokkeert een aanvraag van het aangevraagde type als +
    +
  • "style" en het MIME type niet "text/css" zijn, of
    • +
  • "script" en het MIME type zijn niet een JavaScript MIME type.
    • +
+
+
+ +

Specificaties

+ + + + + + + + + + + + + + +
SpecificatieStatusComment
{{SpecName("Fetch", "#x-content-type-options-header", "X-Content-Type-Options definition")}}{{Spec2("Fetch")}}Initial definition
+ +

Browser compatibiliteit

+ + + +

{{Compat("http.headers.X-Content-Type-Options")}}

+ +

Verder lezen

+ + diff --git a/files/nl/web/http/index.html b/files/nl/web/http/index.html new file mode 100644 index 0000000000..b847d235b5 --- /dev/null +++ b/files/nl/web/http/index.html @@ -0,0 +1,87 @@ +--- +title: HTTP +slug: Web/HTTP +tags: + - HTTP + - NeedsTranslation + - Reference + - TopicStub + - Web + - 'l10n:priority' +translation_of: Web/HTTP +--- +
{{HTTPSidebar}}
+ +

Hypertext Transfer Protocol (HTTP) is een applicatie-laag protocol voor het versturen van hypermedia documenten, zoals HTML. Het was ontworpen voor communicatie tussen web browsers en web servers, maar het kan ook worden gebruikt voor andere doeleinden. HTTP volgt een klassiek client-server model, waarbij een client een verbinding opent om een aanvraag te doen en vervolgens wacht op een reactie. HTTP is een stateless protocol, Dit betekend dat de server geen data (state) bewaard tussen twee aanvragen. Hoewel het meestal gebaseerd is op een TCP/IP laag, kan het ook worden gebruikt op elk andere betrouwbare transport laag; dat houd in, een protocol dat niet ongezien berichten verliest zoals UDP.

+ +
+
+

Tutorials

+ +

Leer hoe je HTTP moet gebruiken met handleidingen en tutorials.

+ +
+
Overzicht van HTTP
+
De basis functies van het client-server protocol: wat het kan doen en het beoogde gebruik.
+
HTTP Cache
+
Caching is erg belangrijk voor snelle websites. Dit artikel beschrijft de verschillende methodes van caching en hoe HTTP Headers gebruikt worden om het te gebruiken.
+
HTTP Cookies
+
Hoe cookies werken is gedefinieerd door RFC 6265. When serving an HTTP request, a server can send a Set-Cookie HTTP header with the response. The client then returns the cookie's value with every request to the same server in the form of a Cookie request header. The cookie can also be set to expire on a certain date, or restricted to a specific domain and path.
+
Cross-Origin Resource Sharing (CORS)
+
Cross-site HTTP requests are HTTP requests for resources from a different domain than the domain of the resource making the request. For instance, an HTML page from Domain A (http://domaina.example/) makes a request for an image on Domain B (http://domainb.foo/image.jpg) via the img element. Web pages today very commonly load cross-site resources, including CSS stylesheets, images, scripts, and other resources. CORS allows web developers to control how their site reacts to cross-site requests.
+
+ +
+
Evolutie van HTTP
+
Een korte beschrijving van de veranderingen van de vroege versies van HTTP, het moderne HTTP/2 en verder.
+
Mozilla web security richtlijnen
+
A collection of tips to help operational teams with creating secure web applications.
+
+ +
+
HTTP Messages
+
Describes the type and structure of the different kind of messages of HTTP/1.x and HTTP/2.
+
Een doorsnee HTTP-sessie
+
LatShows and explains the flow of a usual HTTP session.
+
Connection management in HTTP/1.x
+
Describes the three connection management models available in HTTP/1.x, their strengths, and their weaknesses.
+
+
+ +
+

Referentie

+ +

Blader door gedetailleerde HTTP-referentiedocumentatie.

+ +
+
HTTP Headers
+
HTTP berichtheaders worden gebruikt om een bron of het gedrag van de server of client te beschrijven. Eigen headers kunnen toegevoegd worden door gebruik te maken van het  X- voorvoegsel; anderen in een  IANA-register, waarvan de originele inhoud gedefinieerd is in RFC 4229. IANA houd ook een register van voorgestelde nieuwe HTTP-berichtheaders bij.
+
HTTP Request Methods
+
The different operations that can be done with HTTP: {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}}, and also less common requests like {{HTTPMethod("OPTIONS")}}, {{HTTPMethod("DELETE")}}, or {{HTTPMethod("TRACE")}}.
+
HTTP Status Response Codes
+
HTTP response codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes: informational responses, successful responses, redirections, client errors, and servers errors.
+
+ +
+
CSP-richtlijnen
+
De {{HTTPHeader("Content-Security-Policy")}} antwoordheaderresponse header fields allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints.
+
+ +

Tools en bronnen

+ +

Helpful tools and resources for understanding and debugging HTTP.

+ +
+
Firefox Developer Tools
+
Network monitor
+
Mozilla Observatory
+
+

A project designed to help developers, system administrators, and security professionals configure their sites safely and securely.

+
+
RedBot
+
Tools om je cache-gerelateerde headers te controleren.
+
Hoe Browsers Werken
+
Een zeer uitgebreid artikel over browser internals en het aanvraagverloop door het HTTP protocol. Een MUST-READ voor elke webontwikkelaar.
+
+
+
diff --git a/files/nl/web/http/status/100/index.html b/files/nl/web/http/status/100/index.html new file mode 100644 index 0000000000..366ce793ea --- /dev/null +++ b/files/nl/web/http/status/100/index.html @@ -0,0 +1,48 @@ +--- +title: 100 Continue +slug: Web/HTTP/Status/100 +tags: + - HTTP + - Informatief + - Status code +translation_of: Web/HTTP/Status/100 +--- +
{{HTTPSidebar}}
+ +
De HTTP 100 Continue informatie status reactie code geeft aan dat alles tot nu toe in orde is en dat de client door moet gaan met de aanvraag of het moet negeren wanneer deze al is afgerond.
+ +
 
+ +
Om een server de request's headers te laten checken, moet een client een {{HTTPHeader("Expect")}} : 100-continue versturen als een header in zijn originele aanvraag en een 100 Continue status code ontvangen in de reactie voor dat de body wordt verstuurd.
+ +

Status

+ +
100 Continue
+ +

Specificaties

+ + + + + + + + + + + + +
SpecificatieTitel
{{RFC("7231", "100 Continue" , "6.2.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Browser ondersteuning

+ + + +

{{Compat("http.status.100")}}

+ +

Bekijk ook

+ + diff --git a/files/nl/web/http/status/200/index.html b/files/nl/web/http/status/200/index.html new file mode 100644 index 0000000000..98e26f75df --- /dev/null +++ b/files/nl/web/http/status/200/index.html @@ -0,0 +1,50 @@ +--- +title: 200 OK +slug: Web/HTTP/Status/200 +translation_of: Web/HTTP/Status/200 +--- +
{{HTTPSidebar}}
+ +

De HTTP 200 OK statuscode geeft aan dat het verzoek is geslaagd. Een 200 response kan standaard gecached worden.

+ +

De betekenis van deze status hangt af van de HTTP-requestmethode:

+ + + +

Vaak is het resultaat van een succesvolle {{HTTPMethod("PUT")}} of een {{HTTPMethod("DELETE")}} niet een 200OK maar een {{HTTPStatus("204")}} No Content (of een {{HTTPStatus("201")}} Created als de bron voor de eerste keer geüpload wordt).

+ +

Status

+ +
200 OK
+ +

Specificaties

+ + + + + + + + + + + + +
SpecificatieTitel
{{RFC("7231", "200 OK" , "6.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Browsercompabiliteit

+ + + +

{{Compat("http.status.200")}}

+ +

Zie ook

+ + diff --git a/files/nl/web/http/status/301/index.html b/files/nl/web/http/status/301/index.html new file mode 100644 index 0000000000..7e90b586cd --- /dev/null +++ b/files/nl/web/http/status/301/index.html @@ -0,0 +1,47 @@ +--- +title: 301 Moved Permanently +slug: Web/HTTP/Status/301 +tags: + - HTTP + - Herverbinden + - Referentie + - Status code +translation_of: Web/HTTP/Status/301 +--- +
{{HTTPSidebar}}
+ +

De HTTP 301 Moved Permanently herverbind status reactie code geeft aan dat het opgevraagde onderdeel permanent is verplaatst naar de URL aangegeven in de {{HTTPHeader("Location")}} headers. Een browser herverbind met deze pagina, en zoekmachines updaten hun links naar het onderdeel.

+ +

Zelfs als de specificaties het verplichten de methode, en de body, niet aan te passen wanneer de herverbinding plaatsvind, voldoen niet alle user-agents hieraan. Er wordt nogsteeds gebruik gemaakt van buggy software. Het wordt daarom aangeraden de 301 code alleen als reactie te gebruiken voor {{HTTPMethod("GET")}} of {{HTTPMethod("HEAD")}} methodes en gebruik te maken van {{HTTPStatus("308")}} Permanent Redirect, aangezien de methode aanpassingen uitdrukkelijk verboden zijn met deze status.

+ +

Status

+ +
301 Moved Permanently
+ +

Specificaties

+ + + + + + + + + + + + +
SpecificatieTitel
{{RFC("7231", "301 Redirect Permanently" , "6.4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Browser ondersteuning

+ + + +

{{Compat("http.status.301")}}

+ +

Bekijk ook

+ + diff --git a/files/nl/web/http/status/index.html b/files/nl/web/http/status/index.html new file mode 100644 index 0000000000..e490502369 --- /dev/null +++ b/files/nl/web/http/status/index.html @@ -0,0 +1,171 @@ +--- +title: HTTP response status codes +slug: Web/HTTP/Status +tags: + - HTTP + - NeedsTranslation + - Status codes + - TopicStub +translation_of: Web/HTTP/Status +--- +
{{HTTPSidebar}}
+ +

HTTP response status codes indicate whether a specific HTTP 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 section 10 of RFC 2616.

+ +

Information responses

+ +
+
{{HTTPStatus(100, "100 Continue")}}
+
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.
+
{{HTTPStatus(101, "101 Switching Protocol")}}
+
This code is sent in response to an {{HTTPHeader("Upgrade")}} request header by the client, and indicates the protocol the server is switching too.
+
{{HTTPStatus(102, "102 Processing")}} ({{Glossary("WebDAV")}})
+
This code indicates that the server has received and is processing the request, but no response is available yet.
+
+ +

Successful responses

+ +
+
{{HTTPStatus(200, "200 OK")}}
+
The request has succeeded. The meaning of a success varies depending on the HTTP method:
+ GET: The resource has been fetched and is transmitted in the message body.
+ HEAD: The entity headers are in the message body.
+ POST: The resource describing the result of the action is transmitted in the message body.
+ TRACE: The message body contains the request message as received by the server
+
{{HTTPStatus(201, "201 Created")}}
+
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.
+
{{HTTPStatus(202, "202 Accepted")}}
+
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.
+
{{HTTPStatus(203, "203 Non-Authoritative Information")}}
+
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.
+
{{HTTPStatus(204, "204 No Content")}}
+
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.
+
{{HTTPStatus(205, "205 Reset Content")}}
+
This response code is sent after accomplishing request to tell user agent reset document view which sent this request.
+
{{HTTPStatus(206, "206 Partial Content")}}
+
This response code is used because of range header sent by the client to separate download into multiple streams.
+
{{HTTPStatus(207, "207 Multi-Status")}} ({{Glossary("WebDAV")}})
+
A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate.
+
{{HTTPStatus(208, "208 Multi-Status")}} ({{Glossary("WebDAV")}})
+
Used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly.
+
{{HTTPStatus(226, "226 IM Used")}} (HTTP Delta encoding)
+
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.
+
+ +

Redirection messages

+ +
+
{{HTTPStatus(300, "300 Multiple Choice")}}
+
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.
+
{{HTTPStatus(301, "301 Moved Permanently")}}
+
This response code means that URI of requested resource has been changed. Probably, new URI would be given in the response.
+
{{HTTPStatus(302, "302 Found")}}
+
This response code means that URI of requested resource has been changed temporarily. New changes in the URI might be made in the future. Therefore, this same URI should be used by the client in future requests.
+
{{HTTPStatus(303, "303 See Other")}}
+
Server sent this response to directing client to get requested resource to another URI with an GET request.
+
{{HTTPStatus(304, "304 Not Modified")}}
+
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.
+
305 Use Proxy {{deprecated_inline}}
+
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.
+
306 unused
+
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.
+
{{HTTPStatus(307, "307 Temporary Redirect")}}
+
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 302 Found HTTP response code, with the exception that the user agent must not change the HTTP method used: if a POST was used in the first request, a POST must be used in the second request.
+
{{HTTPStatus(308, "308 Permanent Redirect")}}
+
This means that the resource is now permanently located at another URI, specified by the Location: HTTP Response header. This has the same semantics as the 301 Moved Permanently HTTP response code, with the exception that the user agent must not change the HTTP method used: if a POST was used in the first request, a POST must be used in the second request.
+
+ +

Client error responses

+ +
+
{{HTTPStatus(400, "400 Bad Request")}}
+
This response means that server could not understand the request due to invalid syntax.
+
{{HTTPStatus(401, "401 Unauthorized")}}
+
Although the HTTP standard specifies "unauthorized", semantically this response means "unauthenticated". That is, the client must authenticate itself to get the requested response.
+
402 Payment Required
+
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.
+
{{HTTPStatus(403, "403 Forbidden")}}
+
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.
+
{{HTTPStatus(404, "404 Not Found")}}
+
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.
+
{{HTTPStatus(405, "405 Method Not Allowed")}}
+
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, GET and HEAD, must never be disabled and should not return this error code.
+
{{HTTPStatus(406, "406 Not Acceptable")}}
+
This response is sent when the web server, after performing server-driven content negotiation, doesn't find any content following the criteria given by the user agent.
+
{{HTTPStatus(407, "407 Proxy Authentication Required")}}
+
This is similar to 401 but authentication is needed to be done by a proxy.
+
{{HTTPStatus(408, "408 Request Timeout")}}
+
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.
+
{{HTTPStatus(409, "409 Conflict")}}
+
This response is sent when a request conflicts with the current state of the server.
+
{{HTTPStatus(410, "410 Gone")}}
+
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.
+
{{HTTPStatus(411, "411 Length Required")}}
+
Server rejected the request because the Content-Length header field is not defined and the server requires it.
+
{{HTTPStatus(412, "412 Precondition Failed")}}
+
The client has indicated preconditions in its headers which the server does not meet.
+
{{HTTPStatus(413, "413 Payload Too Large")}}
+
Request entity is larger than limits defined by server; the server might close the connection or return an Retry-After header field.
+
{{HTTPStatus(414, "414 URI Too Long")}}
+
The URI requested by the client is longer than the server is willing to interpret.
+
{{HTTPStatus(415, "415 Unsupported Media Type")}}
+
The media format of the requested data is not supported by the server, so the server is rejecting the request.
+
{{HTTPStatus(416, "416 Requested Range Not Satisfiable")}}
+
The range specified by the Range 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.
+
{{HTTPStatus(417, "417 Expectation Failed")}}
+
This response code means the expectation indicated by the Expect request header field can't be met by the server.
+
{{HTTPStatus(418, "418 I'm a teapot")}}
+
The server refuses the attempt to brew coffee with a teapot.
+
{{HTTPStatus(421, "421 Misdirected Request")}}
+
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.
+
{{HTTPStatus(422, "422 Unprocessable Entity")}} ({{Glossary("WebDAV")}})
+
The request was well-formed but was unable to be followed due to semantic errors.
+
{{HTTPStatus(423, "423 Locked")}} ({{Glossary("WebDAV")}})
+
The resource that is being accessed is locked.
+
{{HTTPStatus(424, "424 Failed Dependency")}} ({{Glossary("WebDAV")}})
+
The request failed due to failure of a previous request.
+
{{HTTPStatus(426, "426 Upgrade Required")}}
+
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).
+
{{HTTPStatus(428, "428 Precondition Required")}}
+
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.
+
{{HTTPStatus(429, "429 Too Many Requests")}}
+
The user has sent too many requests in a given amount of time ("rate limiting").
+
{{HTTPStatus(431, "431 Request Header Fields Too Large")}}
+
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.
+
{{HTTPStatus(451, "451 Unavailable For Legal Reasons")}}
+
The user requests an illegal resource, such as a web page censored by a government.
+
+ +

Server error responses

+ +
+
{{HTTPStatus(500, "500 Internal Server Error")}}
+
The server has encountered a situation it doesn't know how to handle.
+
{{HTTPStatus(501, "501 Not Implemented")}}
+
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 GET and HEAD.
+
{{HTTPStatus(502, "502 Bad Gateway")}}
+
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.
+
{{HTTPStatus(503, "503 Service Unavailable")}}
+
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 Retry-After: 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.
+
{{HTTPStatus(504, "504 Gateway Timeout")}}
+
This error response is given when the server is acting as a gateway and cannot get a response in time.
+
{{HTTPStatus(505, "505 HTTP Version Not Supported")}}
+
The HTTP version used in the request is not supported by the server.
+
{{HTTPStatus(506, "506 Variant Also Negotiates")}}
+
The server has an internal configuration error: transparent content negotiation for the request results in a circular reference.
+
{{HTTPStatus(507, "507 Insufficient Storage")}}
+
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.
+
{{HTTPStatus(508, "508 Loop Detected")}} ({{Glossary("WebDAV")}})
+
The server detected an infinite loop while processing the request.
+
{{HTTPStatus(510, "510 Not Extended")}}
+
Further extensions to the request are required for the server to fulfill it.
+
{{HTTPStatus(511, "511 Network Authentication Required")}}
+
The 511 status code indicates that the client needs to authenticate to gain network access.
+
+ +

See also

+ + -- cgit v1.2.3-54-g00ecf