HTTP headers which cause PREFLIGHT - Clarification? - http

Question

Simple requests are requests that meet the following criteria :
HTTP Method matches (case-sensitive) one of:
HEAD
GET
POST
HTTP Headers matches (case-insensitive):
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type, but only if the value is one of:
application/x-www-form-urlencoded
multipart/form-data
text/plain
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 :
Cache-Control is not on the list
Connection is not on the list
DNT is not is not on the list
User-Agent is not on the list
Accept-Encoding is not on the list
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.

Answer 1

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.

Answer 2

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.