diff options
Diffstat (limited to 'files/pt-pt/web/http')
| -rw-r--r-- | files/pt-pt/web/http/cors/errors/corsdidnotsucceed/index.html | 22 | ||||
| -rw-r--r-- | files/pt-pt/web/http/cors/errors/index.html | 76 | ||||
| -rw-r--r-- | files/pt-pt/web/http/cors/index.html | 570 | ||||
| -rw-r--r-- | files/pt-pt/web/http/headers/allow/index.html | 67 | ||||
| -rw-r--r-- | files/pt-pt/web/http/headers/index.html | 360 | ||||
| -rw-r--r-- | files/pt-pt/web/http/headers/x-content-type-options/index.html | 83 | ||||
| -rw-r--r-- | files/pt-pt/web/http/index.html | 84 | ||||
| -rw-r--r-- | files/pt-pt/web/http/proxy_servers_and_tunneling/index.html | 98 | ||||
| -rw-r--r-- | files/pt-pt/web/http/status/205/index.html | 45 | ||||
| -rw-r--r-- | files/pt-pt/web/http/status/405/index.html | 46 | ||||
| -rw-r--r-- | files/pt-pt/web/http/status/502/index.html | 51 | ||||
| -rw-r--r-- | files/pt-pt/web/http/status/504/index.html | 50 | ||||
| -rw-r--r-- | files/pt-pt/web/http/status/index.html | 185 |
13 files changed, 1737 insertions, 0 deletions
diff --git a/files/pt-pt/web/http/cors/errors/corsdidnotsucceed/index.html b/files/pt-pt/web/http/cors/errors/corsdidnotsucceed/index.html new file mode 100644 index 0000000000..b6b8001ab1 --- /dev/null +++ b/files/pt-pt/web/http/cors/errors/corsdidnotsucceed/index.html @@ -0,0 +1,22 @@ +--- +title: 'Reason: CORS request did not succeed' +slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed +translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed +--- +<div>{{HTTPSidebar}}</div> + +<h2 id="Motivo">Motivo</h2> + +<pre class="syntaxbox">Motivo: O pedido CORS não foi concluído com sucesso</pre> + +<h2 id="O_que_correu_mal">O que correu mal?</h2> + +<p>O {{Glossary("HTTP")}} pedido que faz uso do CORS falhou porque a conexão HTTP falhou a nivel da rede ou do protocolo de conexão. O error não está directamente relacionado com CORS, mas é algum tipo de erro da rede.</p> + +<h2 id="Veja_também">Veja também</h2> + +<ul> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">Erros CORS</a></li> + <li>Glossário: {{Glossary("CORS")}}</li> + <li><a href="/en-US/docs/Web/HTTP/CORS">Introdução ao CORS</a></li> +</ul> diff --git a/files/pt-pt/web/http/cors/errors/index.html b/files/pt-pt/web/http/cors/errors/index.html new file mode 100644 index 0000000000..d1dd12dc75 --- /dev/null +++ b/files/pt-pt/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 +--- +<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/pt-pt/web/http/cors/index.html b/files/pt-pt/web/http/cors/index.html new file mode 100644 index 0000000000..1bfd447c17 --- /dev/null +++ b/files/pt-pt/web/http/cors/index.html @@ -0,0 +1,570 @@ +--- +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 +--- +<div>{{HTTPSidebar}}</div> + +<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 executes 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 <strong>meets all the following conditions</strong>:</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">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(); + } +} +</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 <strong>OTHER</strong> 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 <strong>OTHER THAN</strong> 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">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); + } +} + +...... +</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/16401/preflight_.png" style="height: 555px; width: 538px;"></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 + +<?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] +</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 <code>Content-Type</code> 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">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(); + } +}</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: <origin> | * +</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.</p> + +<pre class="brush: none">Access-Control-Expose-Headers: <field-name>[, <field-name>]* +</pre> + +<p>For example, the following:</p> + +<pre class="brush: none">Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header +</pre> + +<p>…would allow 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: <delta-seconds> +</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: <method>[, <method>]* +</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: <field-name>[, <field-name>]* +</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: <origin> +</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> value can be <code>null</code>, or a URI.</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: <method> +</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: <field-name>[, <field-name>]* +</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 & 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> diff --git a/files/pt-pt/web/http/headers/allow/index.html b/files/pt-pt/web/http/headers/allow/index.html new file mode 100644 index 0000000000..8582cb58f4 --- /dev/null +++ b/files/pt-pt/web/http/headers/allow/index.html @@ -0,0 +1,67 @@ +--- +title: Allow +slug: Web/HTTP/Headers/Allow +tags: + - Cabeçalho de Entidade + - Cabeçalho de HTTP + - HTTP + - Referencia + - cabeçalho +translation_of: Web/HTTP/Headers/Allow +--- +<div>{{HTTPSidebar}}</div> + +<p>O cabeçalho <code><strong>Allow</strong></code> lista os métodos que um recurso suporta.</p> + +<p>Este cabeçalho deve ser enviado se o servidor responder com um código de estado {{HTTPStatus("405")}} <code>Method Not Allowed</code> para indicar que métodos de pedido podem ser utilizados. Um cabeçalho <code>Allowed</code> vazio indica que o recurso não permite métodos de pedido, que podem ocorrer temporariamente para um dado recurso, por exemplo.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Categoria de cabeçalho</th> + <td>{{Glossary("Entity header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>não</td> + </tr> + </tbody> +</table> + +<h2 id="Sintaxe">Sintaxe</h2> + +<pre class="syntaxbox notranslate">Allow: <métodos-de-http> +</pre> + +<h2 id="Diretivos">Diretivos</h2> + +<dl> + <dt><métodos-de-http></dt> + <dd>Uma lista de <a href="/en-US/docs/Web/HTTP/Methods">métodos de pedido HTTP</a> permitidos separados por vírgulas.</dd> +</dl> + +<h2 id="Exemplos">Exemplos</h2> + +<pre class="notranslate">Allow: GET, POST, HEAD</pre> + +<h2 id="Especificações">Especificações</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Especificação</th> + <th scope="col">Titulo</th> + </tr> + <tr> + <td>{{RFC("7231", "Allow", "7.4.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Ver_também">Ver também</h2> + +<ul> + <li>{{HTTPStatus("405")}}</li> + <li>{{HTTPHeader("Server")}}</li> +</ul> diff --git a/files/pt-pt/web/http/headers/index.html b/files/pt-pt/web/http/headers/index.html new file mode 100644 index 0000000000..31ccf98f9f --- /dev/null +++ b/files/pt-pt/web/http/headers/index.html @@ -0,0 +1,360 @@ +--- +title: HTTP headers +slug: Web/HTTP/Headers +tags: + - HTTP + - Headers + - NeedsTranslation + - Networking + - Reference + - TopicStub +translation_of: Web/HTTP/Headers +--- +<div>{{HTTPSidebar}}</div> + +<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 '<code>:</code>', then by its value (without line breaks). Leading white space before the value is ignored.</p> + +<p>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 <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 message headers</a>.</p> + +<p>Headers can be grouped according to their contexts:</p> + +<ul> + <li>{{Glossary("General header")}}: Headers applying to both requests and responses but with no relation to the data eventually transmitted in the body.</li> + <li>{{Glossary("Request header")}}: Headers containing more information about the resource to be fetched or about the client itself.</li> + <li>{{Glossary("Response header")}}: Headers with additional information about the response, like its location or about the server itself (name and version etc.).</li> + <li>{{Glossary("Entity header")}}: Headers containing more information about the body of the entity, like its content length or its MIME-type.</li> +</ul> + +<p>Headers can also be grouped according to how proxies handle them:</p> + +<dl> + <dt><a id="e2e" name="e2e"></a>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 or the client for a response. Intermediate proxies must retransmit end-to-end headers unmodified and caches must store them.</dd> + <dt><a id="hbh" name="hbh"></a>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("Trailer") }}, {{ 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>The following list summaries HTTP headers by their usage category. For an alphabetical list, see the navigation on the left side.</p> + +<h2 id="Authentication">Authentication</h2> + +<dl> + <dt>{{HTTPHeader("WWW-Authenticate")}}</dt> + <dd>Defines the authentication method that should be used to gain access to 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 gain access to 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 the object has been in a proxy cache.</dd> + <dt>{{HTTPHeader("Cache-Control")}}</dt> + <dd>Specifies directives for caching mechanisms in both, requests and responses.</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>A general warning field containing information about possible problems.</dd> +</dl> + +<h2 id="Client_hints">Client hints</h2> + +<dl> + <dt>{{HTTPHeader("Accept-CH")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Content-DPR")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("DPR")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Downlink")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Save-Data")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Viewport-Width")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Width")}}</dt> + <dd>...</dd> +</dl> + +<dl> + <dt> + <h2 id="Conditionals">Conditionals</h2> + </dt> + <dt>{{HTTPHeader("Last-Modified")}}</dt> + <dd>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.</dd> + <dt>{{HTTPHeader("ETag")}}</dt> + <dd>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.</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 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.</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 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.</dd> +</dl> + +<h2 id="Connection_management">Connection management</h2> + +<dl> + <dt>{{HTTPHeader("Connection")}}</dt> + <dd>Controls whether or not 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">Content negotiation</h2> + +<dl> + <dt>{{HTTPHeader("Accept")}}</dt> + <dd>Informs the server about the types of data that can be sent back. It is MIME-type.</dd> + <dt>{{HTTPHeader("Accept-Charset")}}</dt> + <dd>Informs the server about which character set the client is able to understand.</dd> + <dt>{{HTTPHeader("Accept-Encoding")}}</dt> + <dd>Informs the server about the encoding algorithm, usually a compression algorithm, that can be used on the resource sent back.</dd> + <dt>{{HTTPHeader("Accept-Language")}}</dt> + <dd>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).</dd> +</dl> + +<dl> +</dl> + +<h2 id="Controls">Controls</h2> + +<dl> + <dt>{{HTTPHeader("Expect")}}</dt> + <dd>Indicates expectations that need to be fulfilled by the server in order to properly handle the request.</dd> + <dt>{{HTTPHeader("Max-Forwards")}}</dt> + <dd>...</dd> +</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>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.</dd> + <dt>{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}</dt> + <dd>Used to send cookies from the server to the user agent, but has been obsoleted by the specification. Use {{HTTPHeader("Set-Cookie")}} instead.</dd> + <dt> + <h2 id="CORS">CORS</h2> + </dt> + <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 or not 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 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 method or 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> +</dl> + +<h2 id="Do_Not_Track">Do Not Track</h2> + +<dl> + <dt>{{HTTPHeader("DNT")}}</dt> + <dd>Used for expressing the user's tracking preference.</dd> + <dt>{{HTTPHeader("Tk")}}</dt> + <dd>Indicates the tracking status that applied to the corresponding request.</dd> +</dl> + +<h2 id="Downloads">Downloads</h2> + +<dl> + <dt>{{HTTPHeader("Content-Disposition")}}</dt> + <dd>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.</dd> +</dl> + +<h2 id="Message_body_information">Message body information</h2> + +<dl> + <dt>{{HTTPHeader("Content-Length")}}</dt> + <dd>indicates the size of the entity-body, in decimal number of octets, sent to the recipient.</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 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> + <dt> + <h2 id="Proxies">Proxies</h2> + </dt> +</dl> + +<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 support 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("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("Public-Key-Pins")}} ({{Glossary("HPKP")}})</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> + +<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> +</dl> + +<dl> + <dt>{{HTTPHeader("X-Content-Type-Options")}}</dt> + <dd>Disables MIME sniffing and forces browser to use the type given in {{HTTPHeader("Content-Type")}}.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("X-Frame-Options")}} (XFO)</dt> + <dd>Indicates whether or not a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}} or {{HTMLElement("object")}}</dd> + <dt>{{HTTPHeader("X-XSS-Protection")}}</dt> + <dd>Enables cross-site scripting filtering.</dd> +</dl> + +<h2 id="Server-sent_events">Server-sent events</h2> + +<dl> + <dt>{{HTTPHeader("Ping-From")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Ping-To")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Last-Event-ID")}}</dt> + <dd>...</dd> +</dl> + +<h2 id="Transfer_coding">Transfer coding</h2> + +<dl> + <dt>{{HTTPHeader("Transfer-Encoding")}}</dt> + <dd>Specifies the 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("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>...</dd> + <dt>{{HTTPHeader("Retry-After")}}</dt> + <dd>Indicates how long the user agent should wait before making a follow-up request.</dd> + <dt>{{HTTPHeader("Upgrade")}}</dt> + <dd>This is a Proposed Internet Standard. To view a comprehensive list of all Official and Proposed Internet Standards with detailed information about each, <a href="https://www.rfc-editor.org/standards">visit this Internet Standards reference</a>, which is updated daily. The relevant RFC document for the <a href="https://tools.ietf.org/html/rfc7230#section-6.7">Upgrade header field standard 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. 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 <a href="https://tools.ietf.org/html/rfc7230#section-6.1">please see section 6.1 of the aforementioned RFC</a>.</dd> + <dt>{{HTTPHeader("Vary")}}</dt> + <dd>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.</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-Requested-With")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("X-UA-Compatible")}}</dt> + <dd>...</dd> +</dl> + +<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> +</ul> diff --git a/files/pt-pt/web/http/headers/x-content-type-options/index.html b/files/pt-pt/web/http/headers/x-content-type-options/index.html new file mode 100644 index 0000000000..c237f7b7cf --- /dev/null +++ b/files/pt-pt/web/http/headers/x-content-type-options/index.html @@ -0,0 +1,83 @@ +--- +title: X-Content-Type-Options +slug: Web/HTTP/Headers/X-Content-Type-Options +tags: + - Cabeçalho de Resposta + - Cabeçalhos HTTP + - HTTP + - Referencia +translation_of: Web/HTTP/Headers/X-Content-Type-Options +--- +<div>{{HTTPSidebar}}</div> + +<p>Na resposta HTTP o cabeçalho <code><strong>X-Content-Type-Options</strong></code> é um marcador utilizado pelo servidor para indicar the os <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">tipos de MIME</a> anunciados nos cabeçalhos {{HTTPHeader("Content-Type")}} não devem ser alterados e seguidos. Isto permite evitar <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#MIME_sniffing">inspecção do tipo de MIME</a>, ou, noutras palavras, é uma de dizer que os webmasters sabem o que estão a fazer.</p> + +<p>Este cabeçalho foi introduzido pela Microsoft no IE 8 como uma maneira de os webmasters bloquearem a inspecção de conteúdo que acontecia e podia transformar tipos MIME não executáveis em tipos de MIME executáveis. Desde então, outros browsers também o introduziram, mesmo que os seus algoritmos de inspecção MIME fossem menos agressivos.</p> + +<p>Testadores de segurança esperam que este cabeçalho esteja definido.</p> + +<p class="note">Nota: <code>nosniff</code> apenas se aplica a "<code>script</code>" e tipos de "<code>style</code>". Aplicando também <code>nosniff</code> a imagens acabou por se tornar <a href="https://github.com/whatwg/fetch/issues/395">incompatível com sites web existentes</a>.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Tipo de Cabeçalho</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="Sintaxe">Sintaxe</h2> + +<pre class="syntaxbox">X-Content-Type-Options: nosniff +</pre> + +<h2 id="Directivas">Directivas</h2> + +<dl> + <dt><code>nosniff</code></dt> + <dd>Bloqueia um pedido se o tipo pedido é + <ul> + <li>"<code>style</code>" e o tipo MIME não é "<code>text/css</code>", ou</li> + <li>"<code>script</code>" e o tipo MIME não é do <a href="https://html.spec.whatwg.org/multipage/scripting.html#javascript-mime-type">tipo MIME JavaScript</a>.</li> + </ul> + </dd> +</dl> + +<h2 id="Especificações">Especificações</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Especificação</th> + <th scope="col">Estado</th> + <th scope="col">Comentário</th> + </tr> + <tr> + <td>{{SpecName("Fetch", "#x-content-type-options-header", "X-Content-Type-Options definition")}}</td> + <td>{{Spec2("Fetch")}}</td> + <td>Definição inicial</td> + </tr> + </tbody> +</table> + +<h2 id="Compatibilidade_do_Browser">Compatibilidade do Browser</h2> + +<p class="hidden">A tabela de compatibilidade nesta página é gerada a partir de informação estruturada. Se quiser contribuir para a informação, por favor confira em <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> e envie-nos um pedido de pull.</p> + +<p>{{Compat("http/headers/x-content-type-options")}}</p> + +<h2 id="Veja_também">Veja também</h2> + +<ul> + <li>{{HTTPHeader("Content-Type")}}</li> + <li>A <a href="https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/">definição original</a> de X-Content-Type-Options da Microsoft.</li> + <li>A ferramenta de teste de configuração <a href="https://mozilla.github.io/http-observatory-website/">Mozilla Observatory</a> (incluindo este cabeçalho) de sites web para segurança.</li> + <li> + <p><a href="https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox/">Mitigando Ataques de Confusão MIME no Firefox</a></p> + </li> +</ul> diff --git a/files/pt-pt/web/http/index.html b/files/pt-pt/web/http/index.html new file mode 100644 index 0000000000..f76e190701 --- /dev/null +++ b/files/pt-pt/web/http/index.html @@ -0,0 +1,84 @@ +--- +title: HTTP +slug: Web/HTTP +tags: + - HTTP + - NeedsTranslation + - Reference + - TopicStub + - Web + - 'l10n:priority' +translation_of: Web/HTTP +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><span class="seoSummary"><strong><dfn>Hypertext Transfer Protocol (HTTP)</dfn></strong> é um protocolo da <a class="external" href="https://en.wikipedia.org/wiki/Application_Layer">camada de aplicação</a> para a transmissão de documentos de hipermídia, tal com HTML.</span> Ele foi projetado para a comunicação entre navegadores web e servidores web, mas ele também pode ser usado para outros propósitos. HTTP segue o clássico <a class="external" href="https://en.wikipedia.org/wiki/Client%E2%80%93server_model">Modelo cliente-servidor</a>, com um cliente abrindo uma conexão para fazer uma requisição, e então esperando até que ele receba uma resposta. HTTP é um <a href="https://pt.wikipedia.org/wiki/Protocolo_sem_estado">protocolo sem estado</a>, significando que o servidor não manterá qualquer dado (estado) entre duas requisições. Apesar de frequentemente ser baseado na camada TCP/IP, ele pode ser utilizado em qualquer camada de transporte confiável; isto é, um protocolo que não perda menssagens silenciosamente tal como UDP.</p> + +<div class="column-container"> +<div class="column-half"> +<h2 id="Tutorials">Tutorials</h2> + +<p>Learn how to use HTTP with guides and tutorials.</p> + +<dl> + <dt><a href="/en-US/docs/Web/HTTP/Overview">Overview of HTTP</a></dt> + <dd>The basic features of the client-server protocol: what it can do and its intended uses.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Caching">HTTP Cache</a></dt> + <dd>Caching is very important for fast Web sites. This article describes different methods of caching and how to use HTTP Headers to control them.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Cookies">HTTP Cookies</a></dt> + <dd>How cookies work is defined by <a class="external" href="http://tools.ietf.org/html/rfc6265">RFC 6265</a>. When serving an HTTP request, a server can send a <code>Set-Cookie</code> 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 <code>Cookie</code> request header. The cookie can also be set to expire on a certain date, or restricted to a specific domain and path.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Access_control_CORS">HTTP Access Control (CORS)</a></dt> + <dd><strong>Cross-site HTTP requests</strong> are HTTP requests for resources from a <strong>different domain</strong> than the domain of the resource making the request. For instance, an HTML page from Domain A (<code>http://domaina.example/</code>) makes a request for an image on Domain B (<code>http://domainb.foo/image.jpg</code>) via the <code>img</code> 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.</dd> +</dl> + +<dl> + <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">Evolution of HTTP</a></dt> + <dd>A brief description of the changes between the early versions of HTTP, to the modern HTTP/2 and beyond.</dd> + <dt><a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security">Mozilla web security guidelines</a></dt> + <dd>A collection of tips to help operational teams with creating secure web applications.</dd> +</dl> + +<dl> + <dt><a href="/en-US/docs/Web/HTTP/Messages">HTTP Messages</a></dt> + <dd>Describes the type and structure of the different kind of messages of HTTP/1.x and HTTP/2.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Session">A typical HTTP session</a></dt> + <dd>Shows and explains the flow of a usual HTTP session.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Connection management in HTTP/1.x</a></dt> + <dd>Describes the three connection management models available in HTTP/1.x, their strengths, and their weaknesses.</dd> +</dl> +</div> + +<div class="column-half"> +<h2 id="Reference">Reference</h2> + +<p>Browse through detailed HTTP reference documentation.</p> + +<dl> + <dt><a href="/en-US/docs/Web/HTTP/Headers">HTTP Headers</a></dt> + <dd>HTTP message headers are used to describe a resource, or the behavior of the server or the client. Custom proprietary headers can be added using the <code>X-</code> prefix; others 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 message headers</a>.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Methods">HTTP Request Methods</a></dt> + <dd>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")}}.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Response_codes">HTTP Status Response Codes</a></dt> + <dd>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.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Headers/Content-Security-Policy">CSP directives</a></dt> + <dd>The {{HTTPHeader("Content-Security-Policy")}} response 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.</dd> +</dl> + +<h2 id="Tools_resources">Tools & resources</h2> + +<p>Helpful tools and resources for understanding and debugging HTTP.</p> + +<dl> + <dt><a href="/en-US/docs/Tools">Firefox Developer Tools</a></dt> + <dd><a href="/en-US/docs/Tools/Network_Monitor">Network monitor</a></dd> + <dt><a href="https://observatory.mozilla.org/">Mozilla Observatory</a></dt> + <dd> + <p>A project designed to help developers, system administrators, and security professionals configure their sites safely and securely.</p> + </dd> + <dt><a class="external" href="https://redbot.org/">RedBot</a></dt> + <dd>Tools to check your cache-related headers</dd> + <dt><a href="http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/">How Browsers Work</a></dt> + <dd>A very comprehensive article on browser internals and request flow through HTTP protocol. A MUST-READ for any web developer.</dd> +</dl> +</div> +</div> diff --git a/files/pt-pt/web/http/proxy_servers_and_tunneling/index.html b/files/pt-pt/web/http/proxy_servers_and_tunneling/index.html new file mode 100644 index 0000000000..38c03ba2a2 --- /dev/null +++ b/files/pt-pt/web/http/proxy_servers_and_tunneling/index.html @@ -0,0 +1,98 @@ +--- +title: Servidor Proxy e Túneis +slug: Web/HTTP/Proxy_servers_and_tunneling +tags: + - HTTP + - Proxies + - Proxy + - Túnel HTTP +translation_of: Web/HTTP/Proxy_servers_and_tunneling +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">Ao navegar por diferentes redes da internet, os servidores proxy e os túneis HTTP facilitam o acesso ao conteúdo na Rede Mundial de Computadores (World Wide Web). O proxy pode estar no computador local do usuário, ou em algum lugar entre o computador deste e o servidor de destino na Internet. Esta página é um esquema de conceitos básicos sobre proxies e algumas opções de configuração.</p> + +<p>Há dois tipos de proxies: <strong>proxy de envio </strong> (do inglês "<strong>forward proxies", </strong>ou túnel, ou ainda, gateway) e<strong> proxy reverso</strong> ("<strong>reverse proxies" </strong>usados para proteger o acesso ao servidor de largura de banda, autenticação, decriptação ou caching).</p> + +<h2 id="Proxy_de_Envio">Proxy de Envio</h2> + +<p>Proxy de envio, também chamado gateway ou "proxy" fornece serviços a um cliente ou grupo de clientes. É possível que haja centenas de milhares de proxies de envio livres na Internet. Estes armazenam e enviam serviços de rede (como o DNS, ou páginas da web) para economia e controle da largura de banda usada pelo grupo.</p> + +<p>Proxies de envio também podem ser anónimos e esconder o endereço IP dos usuários que navegam pela Web ou usam outros serviços de Internet. O <a href="https://www.torproject.org/">TOR</a> (The Onion Router), para ser anónimo, roteia tráfego de rede por vários proxies .</p> + +<h2 id="Proxy_reverso">Proxy reverso</h2> + +<p>Como o nome já indica, faz o inverso do proxy de envio: O proxy de envio benefecia a clientes (ou a hosts que o requisitam), já o proxy reverso benefecia a servidores. Proxies de envio podem esconder a identidade de clientes, ao passo que proxies reversos podem esconder a dos servidores. Proxies reversos tem várias funções, dentre os quais:</p> + +<ul> + <li>Load balancing: distribuir a carga por vários servidores web ,</li> + <li>Cache de conteúdo estático: liberta os servidores web por esconder conteúdo estático, como fotos</li> + <li>Compressão: acelera o tempo de carregamento por comprimir e otimizar conteúdos</li> +</ul> + +<h2 id="Envio_de_informação_de_clientes_por_meio_de_proxies">Envio de informação de clientes por meio de proxies</h2> + +<p>Proxies fazem parecer que os pedidos vêm do endereço IP do proxy. Isto pode ser útil se o proxy provê anonimato ao cliente. Porém, noutros casos, perde-se a informação do pedido original. O endereço IP original é usado em verificação de erros, em estatísticas ou ao gerar conteúdo ajustado à localização. Uma forma comum de divulgar esta informação é usando estes cabeçalhos HTTP:</p> + +<p>Cabeçalho padronizado:</p> + +<dl> + <dt>{{HTTPHeader("Forwarded")}}</dt> + <dd>Contêm informação do lado do cliente de proxy, que foi alterada ou perdida se há um proxy no caminho do pedido</dd> +</dl> + +<p>Ou as versões de facto padrão:</p> + +<dl> + <dt>{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}</dt> + <dd>Identifica o endereço IP de origem do cliente que se conectou ao servidor web por meio de um proxy HTTP ou um load balancer</dd> + <dt>{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}</dt> + <dd>Identifica o Host originalmente requisitado pelo cliente, quando este se conectou ao seu proxy ou load balancer </dd> + <dt>{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}</dt> + <dd>Identifica o protocolo (HTTP ou HTTPS) que o cliente usou ao se conectar ao seu proxy ou load balancer</dd> +</dl> + +<p>Pode-se usar o cabeçalho <code>Via</code> para informar, não sobre o cliente conectado, mas sobre o próprio proxy.</p> + +<dl> + <dt>{{HTTPHeader("Via")}}</dt> + <dd>Adicionado por proxies, tanto de envio como reversos, e aparece no cabeçalho do pedido e da resposta.</dd> +</dl> + +<h2 id="Túnel_HTTP">Túnel HTTP </h2> + +<p>O Tunelamento encapsula os dados, permitindo assim que dados de rede privada e protocolos traféguem em redes públicas. Tunelamento HTTP é usar o protocolo de alto nível (HTTP) para transportar outro de nível abaixo (TCP).</p> + +<p>O Protocolo HTTP protocol especifica o método {{HTTPMethod("CONNECT")}}. Este começa comunicações de mão-dupla com o recurso requisitado e pode abrir um túnel. É assim que o cliente de proxy HTTP pode acessar websites a usar SSL (i.e. HTTPS, porta 443). Mas, é digno de nota, que nem todos os servidores proxy tem suporte ao método <code>CONNECT</code> ou limitam-no à porta 443.</p> + +<p>Veja também o artigo <a href="https://en.wikipedia.org/wiki/HTTP_tunnel">HTTP tunnel</a>, na Wikipedia.</p> + +<h2 id="Proxy_Auto-Configuration_PAC">Proxy Auto-Configuration (PAC)</h2> + +<p>O ficheiro <a href="/en-US/docs/Mozilla/Projects/Necko/Proxy_Auto-Configuration_(PAC)_file">Proxy Auto-Configuration (PAC)</a> é uma função de <a href="https://wiki.developer.mozilla.org/pt-PT/docs/Web/JavaScript">JavaScript</a> que determina se pedidos de motores de busca (HTTP, HTTPS, e FTP) vão direto ao destino ou são reencaminhadas a um proxy-servidor web. A função JavaScript contida no ficheiro PAC define:</p> + +<p id="Saving_the_Auto-Config_File_Setting_the_MIME_Type">O ficheiro auto-config será salvo com extensão <code>.pac</code>:</p> + +<pre class="syntaxbox notranslate">proxy.pac</pre> + +<p>E o MIME type é configurado para:</p> + +<pre class="syntaxbox notranslate">application/x-ns-proxy-autoconfig</pre> + +<p>O Ficheiro consiste numa função de nome <code>FindProxyForURL</code>. Se o servidor DNS interno está configurado para fonecer nomes à hosts internos, e o objectivo é usar um proxy só para hosts sem nome, então este exemplo deve funcionar:</p> + +<pre class="brush: js notranslate">function FindProxyForURL(url, host) { + if (isResolvable(host)) + return "DIRECT"; + else + return "PROXY proxy.mydomain.com:8080"; +}</pre> + +<p>Veja <a href="/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_(PAC)_file">Proxy Auto-Configuration (PAC)</a> para mais exemplos.</p> + +<h2 id="Veja_também">Veja também</h2> + +<ul> + <li>{{HTTPMethod("CONNECT")}}</li> + <li><a href="https://pt.wikipedia.org/wiki/Proxy">Proxy na Wikipedia</a></li> +</ul> diff --git a/files/pt-pt/web/http/status/205/index.html b/files/pt-pt/web/http/status/205/index.html new file mode 100644 index 0000000000..abd4774ca7 --- /dev/null +++ b/files/pt-pt/web/http/status/205/index.html @@ -0,0 +1,45 @@ +--- +title: 205 Reset Content +slug: Web/HTTP/Status/205 +tags: + - Códigos de resposta + - Códigos de resposta HTTP + - HTTP + - HTTP Status Code + - Referencia +translation_of: Web/HTTP/Status/205 +--- +<div>{{HTTPSidebar}}</div> + +<p>O código de resposta HTTP <strong><code>205 Reset Content</code></strong> indica ao cliente que deve reinicializar a vista do documento. Assim, por exemplo, deve limpar o conteúdo de um formulário, reiniciar o estado de uma tela ou refrescar o UI.</p> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox">205 Reset Content</pre> + +<h2 id="Especificações">Especificações</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "205 Reset Content" , "6.3.6")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Notas_sobre_compatibilidade">Notas sobre compatibilidade</h2> + +<ul> + <li>O comportamento dos navegadores difere para o caso de esta resposta incluir erradamente um corpo em ligações persistentes. Para mais detalhe, veja <a href="/en-US/docs/Web/HTTP/Status/204">204 No Content</a>.</li> +</ul> + +<h2 id="Ver_também">Ver também</h2> + +<ul> + <li>{{HTTPStatus(204)}} No Content</li> +</ul> diff --git a/files/pt-pt/web/http/status/405/index.html b/files/pt-pt/web/http/status/405/index.html new file mode 100644 index 0000000000..abe104da6b --- /dev/null +++ b/files/pt-pt/web/http/status/405/index.html @@ -0,0 +1,46 @@ +--- +title: 405 Method Not Allowed +slug: Web/HTTP/Status/405 +tags: + - Código de resposta HTTP + - Erro de cliente + - HTTP + - Referencia + - Status code +translation_of: Web/HTTP/Status/405 +--- +<div>{{HTTPSidebar}}</div> + +<p>O código de resposta HTTP (HyperText Transfer Protocol) <code>405 Method Not Allowed</code> indica que o método do pedido é conhecido pelo servidor, mas não é suportado pelo recurso alvo.</p> + +<p class="newpage">O servidor PRECISA gerar um campo de cabeçalho chamado <code>Allow</code> numa resposta 405 contendo uma lista dos métodos que o recurso alvo atualmente suporta.</p> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox notranslate">405 Method Not Allowed</pre> + +<h2 id="Especificações">Especificações</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Especificação</th> + <th scope="col">Titulo</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("7231", "405 Method Not Allowed", "6.5.5")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Ver_também">Ver também</h2> + +<ul> + <li>{{HTTPHeader("Allow")}}</li> + <li><em><a href="https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" rel="noopener">HTTP/1.1: Status Code Definitions</a></em></li> + <li><em><a href="https://kinsta.com/blog/405-method-not-allowed-error/">How to Fix 405 Method Not Allowed</a></em></li> + <li><em><a href="https://docs.microsoft.com/en-us/aspnet/web-api/overview/testing-and-debugging/troubleshooting-http-405-errors-after-publishing-web-api-applications">Troubleshooting HTTP 405</a></em></li> +</ul> diff --git a/files/pt-pt/web/http/status/502/index.html b/files/pt-pt/web/http/status/502/index.html new file mode 100644 index 0000000000..548e89fd57 --- /dev/null +++ b/files/pt-pt/web/http/status/502/index.html @@ -0,0 +1,51 @@ +--- +title: 502 Bad Gateway +slug: Web/HTTP/Status/502 +tags: + - Erro de servidor + - HTTP + - Status code +translation_of: Web/HTTP/Status/502 +--- +<div>{{HTTPSidebar}}</div> + +<p>O código de resposta HTTP (Protocolo de Transferência de Hipertexto) <code><strong>502 Bad Gateway</strong></code> indica que o servidor, ao agir como portal ou <em>proxy</em>, recebeu uma resposta invalida dum servidor <em>upstream</em> (um servidor mais adiante na cadeia de conexões).</p> + +<div class="note"> +<p><strong>Nota: </strong>Uma {{interwiki("wikipedia", "Gateway", "Gateway")}} pode ser várias coisas numa rede e um erro 502 tipicamente não pode ser resolvido por si, mas requer um conserto no servidor ou nas <em>proxies</em> por qual esta a comunicar.</p> +</div> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox notranslate">502 Bad Gateway +</pre> + +<h2 id="Especificações">Especificações</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Especificação</th> + <th scope="col">Titulo</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("7231", "502 Bad Gateway", "6.6.3")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Compatibilidade">Compatibilidade</h2> + +<div 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 class="external" href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</div> + +<p>{{Compat("http.status.502")}}</p> + +<h2 id="Veja_também">Veja também</h2> + +<ul> + <li>{{HTTPStatus(504)}}</li> + <li><a href="https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" rel="noopener">HTTP/1.1: Status Code Definitions</a></li> +</ul> diff --git a/files/pt-pt/web/http/status/504/index.html b/files/pt-pt/web/http/status/504/index.html new file mode 100644 index 0000000000..ce2ddf7563 --- /dev/null +++ b/files/pt-pt/web/http/status/504/index.html @@ -0,0 +1,50 @@ +--- +title: 504 Gateway Timeout +slug: Web/HTTP/Status/504 +tags: + - Erro de servidor + - HTTP + - Status code +translation_of: Web/HTTP/Status/504 +--- +<div>{{HTTPSidebar}}</div> + +<p>O código de resposta HTTP (Protocolo de Transferência de Hipertexto) <code><strong>504 Gateway Timeout</strong></code> indica que o servidor, ao agir como portal ou <em>proxy</em>, não recebeu uma resposta dum servidor <em>upstream</em> (um servidor mais adiante na cadeia de conexões) no tempo necessário para completar a resposta. </p> + +<div class="note"> +<p><strong>Nota</strong>: Uma {{interwiki("wikipedia", "Gateway", "Gateway")}} pode ser várias coisas numa rede e um erro 504 tipicamente não pode ser resolvido por si, mas requer um conserto no servidor ou nas <em>proxies</em> por qual esta a comunicar.</p> +</div> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox notranslate">504 Gateway Timeout</pre> + +<h2 id="Especificações">Especificações</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Especificação</th> + <th scope="col">Titulo</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("7231", "504 Gateway Timeout" , "6.6.5")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Compatibilidade">Compatibilidade</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.504")}}</p> + +<h2 id="Veja_também">Veja também</h2> + +<ul> + <li><a href="https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" rel="noopener">HTTP/1.1: Status Code Definitions</a></li> + <li>{{HTTPStatus(502)}}</li> +</ul> diff --git a/files/pt-pt/web/http/status/index.html b/files/pt-pt/web/http/status/index.html new file mode 100644 index 0000000000..cc6e9b9e37 --- /dev/null +++ b/files/pt-pt/web/http/status/index.html @@ -0,0 +1,185 @@ +--- +title: HTTP response status codes +slug: Web/HTTP/Status +tags: + - HTTP + - Landing + - NeedsTranslation + - Overview + - Reference + - Status codes + - TopicStub + - Web +translation_of: Web/HTTP/Status +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><span class="seoSummary">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.</span> 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 to.</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> + <dt>{{HTTPStatus(103, "103 Early Hints")}}</dt> + <dd>This status code is primarily intended to be used with the {{HTTPHeader("Link")}} header to allow the user agent to start preloading resources while the server is still preparing a response.</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> + PUT or 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 POST request, or after some PUT requests.</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 response. The user-agent or user should choose one of them. There is no standardized way of choosing one of the responses.</dd> + <dt>{{HTTPStatus(301, "301 Moved Permanently")}}</dt> + <dd>This response code means that the URI of the requested resource has been changed permanently. Probably, the new URI would be given in the response.</dd> + <dt>{{HTTPStatus(302, "302 Found")}}</dt> + <dd>This response code means that the 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>The server sent this response to direct the client to get the requested resource at another URI with a GET request.</dd> + <dt>{{HTTPStatus(304, "304 Not Modified")}}</dt> + <dd>This is used for caching purposes. It tells the client that the response has not been modified, so the client can continue to use the same cached version of the 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>The server sends this response to direct the client to get the requested resource at another URI with same method that was used in the prior request. This has the same semantics as 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 permanently 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(425, "425 Too Early")}}</dt> + <dd>Indicates that the server is unwilling to risk processing a request that might be replayed.</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="Browser_compatibility">Browser compatibility</h2> + + + +<p>{{Compat("http.status")}}</p> + +<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> |