CODEWITHSUNDEEP
httphttp-headerscorspreflight
Royi Namir
Royi Namir

Reputation: 148524

HTTP headers which cause PREFLIGHT - Clarification?

Simple requests are requests that meet the following criteria :

But looking at this test page which is not causing preflight request :

General : 

Remote Address:69.163.243.142:80
Request URL:http://aruner.net/resources/access-control-with-get/
Request Method:GET
Status Code:200 OK

Request Headers

Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8,he;q=0.6
Cache-Control:no-cache
Connection:keep-alive
DNT:1
Host:aruner.net
Origin:http://arunranga.com
Pragma:no-cache
Referer:http://arunranga.com/examples/access-control/simpleXSInvocation.html
User-Agent:Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36

Response Headers

Access-Control-Allow-Origin:http://arunranga.com
Connection:Keep-Alive
Content-Type:application/xml
Date:Sat, 26 Sep 2015 09:00:26 GMT
Keep-Alive:timeout=2, max=100
Server:Apache
Transfer-Encoding:chunked

Being pedantic and looking at the request section , There are many headers which are not in the preceding criteria section :

I know that those are more of "general" headers. But so does accept-language

Question

What am I missing here? According to the criteria section, a request with those headers should cause a preflight request.

Upvotes: 3

Views: 582

Answers (2)

sideshowbarker
sideshowbarker

Reputation: 88026

As further clarification on top of the accepted answer: See the HTTP header layer division section of the Fetch Standard (where the CORS protocol and UA requirements are defined these days).

For the purposes of fetching, the platform has an API layer (HTML's img, CSS' background-image), early fetch layer, service worker layer, and network & cache layer. Accept and Accept-Language are set in the early fetch layer (typically by the user agent). Most other headers controlled by the user agent, such as Accept-Encoding, Host, and Referer, are set in the network & cache layer. Developers can set headers either at the API layer or in the service worker layer (typically through a Request object).

So, based on that, we can essentially say:

  • the headers in the question are controlled by the UA, and set in the “network & cache layer”
  • so, the headers are not headers that developers can set in the “API layer“
  • so, the headers have not yet been set at the point when the algorithm runs for determining if a preflight request is required (instead they’re set by the UA later, after that’s already been done)

Then, given the above, despite the fact those headers can be seen in the request, we know they have played no part in the determination of whether a preflight should have been required.

In other words, those headers are essentially irrelevant to CORS. And so also, the only headers that are relevant are those that developers manually set in the “API layer” or service-worker layer.

Upvotes: 3

SilverlightFox
SilverlightFox

Reputation: 33538

Looking at your code:

    invocation.open('GET', url, true);
    invocation.onreadystatechange = handler;
    invocation.send();

You are not actually setting any custom headers. e.g.

    invocation.setRequestHeader("X-Requested-With", "XMLHttpRequest");

Therefore there will be no preflight. Default browser headers do not count. The preflight mechanism is only there to ensure any custom headers, such as the one in my example above, are allowed to be passed cross domain by the receiving site.

Upvotes: 2

Related Questions