Edit this page
Defaults that are added automatically on requests when using EAS Hosting.
EAS Hosting applies several defaults to your deployment that are supposed to help you and reduce the amount of code you have to add yourself for simple API routes.
An asset response contains additional metadata headers for browsers, mostly for caching.
A default ETag
header is added to all asset responses to allow browsers to re-validate their caches using if-none-match
request headers.
By default, if an API route does not handle OPTIONS
requests, EAS Hosting will automatically respond with a default CORS response.
This default is very permissible and generally allows all browsers to make requests to the API route. If you don't want this, handle OPTIONS
requests in API routes yourself.
The following headers will be sent by default:
Access-Control-Allow-Origin: <origin || '*'>
Access-Control-Allow-Headers: <access-control-request-headers || '*'>,
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: *
Access-Control-Max-Age: 3600
Vary: Origin, Access-Control-Request-Headers
These headers will allow any client to make a request from any origin, with any headers, with credentials, and cache the OPTIONS
response for 3600 seconds.
More information on preflight OPTIONS
requests can be found in the MDN documentation.
This header tells browsers to only access a URL with the HTTPS protocol in the future. EAS Hosting automatically adds this header if it's missing.
Its default value is set to max-age=31536000; includeSubDomains; preload
.
For more information on why this header is a good default, improves security, and performance, read this article on web.dev
and read more about Strict-Transport-Security header in the MDN documentation.
By default, EAS Hosting will remove and not forward any X-Powered-By
and X-Aspnet-Version
headers. With API routes, this header does not serve much of a purpose and we don't recommend you add alternative headers like X-Powered-By
to your API routes as it unnecessarily exposes internal information on the code you're running.
By default, browsers allow any webpage to render in an iframe. Unfortunately, this allows phishing attacks such as clickjacking which is used by malicious actors to overlay a page with their own controls and inputs, to steal credentials or coerce users to perform certain actions.
To prevent this, EAS Hosting adds a frame-ancestors 'self'
directive by default, telling browsers to not embed EAS Hosting in iframes on other domains that you don't control.
This is equivalent to setting the (older) X-Frame-Options
header to SAMEORIGIN
.This default directive is only applied to responses with text/html
content types, so it will only be applied to HTML pages.
If your API routes respond with custom X-Frame-Options
headers, these headers will automatically be converted to Content-Security-Policy
directives in your response.
If your API route throws an unhandled JavaScript error, this is treated as a "crash" since your API route was unable to deliver an error.
EAS Hosting will respond with an error page in these cases. The error page will be rendered as an HTML response, if the Accept: text/html
request header was sent. Otherwise, it will only respond with a plaintext response.
EAS Hosting will add a couple of headers to every request, before it's forwarded to your API routes. These headers generally add more information about who made the request.
The request contains several headers to identify the IP address of the user's device that made the request:
Forwarded
is a standard header that delivers a comma-separated list of forwarder IPs for the given request. See MDN documentation on HTTP Forwarded
header for more information.X-Forwarded-For
is a de-facto standard header that is set to a comma-separated list of the forwarder IPs for a given request without any added information.X-Forwarded-For
contains a list of protocols used to forward the request, typically it's set to https
X-Real-IP
contains only the original request's IP addressFor example, to retrieve the IP address of the user's browser that is calling your API route, read the X-Real-IP
header from the request:
export async function GET(request) {
const ip = request.headers.get('X-Real-IP');
}
The request also contains several headers containing geographical information about where the request came from:
eas-colo
contains the Cloudflare code for the data center that handled your request. For example, lhr
.eas-ip-continent
contains the continent code of the current request:
AF
for AfricaAN
for AntarcticaAS
for AsiaEU
for EuropeNA
for North AmericaOC
for OceaniaSA
for South America.eas-ip-country
contains the ISO-3166 Alpha 2 country code. This is at most two letters long. For example, US
or JP
.eas-ip-region
contains the ISO-3166-2 region code for the request. This value is a maximum of three characters long. However, it can vary based on how region codes in a specific country work for the requested origin.. It could comprise one to three digits, one to three letters, or any other combination.eas-ip-city
may contain a human-readable name of a city. For example London
or Chicago
.eas-ip-latitude
and eas-ip-longitude
contain an approximate latitude and longitude for the request.eas-ip-timezone
contains a best guess of the timezone the request originated in. For example, Europe/London
eas-ip-eu
is set to 1
when the request likely originated in the jurisdictional area of the European Union.