Execution order of Http Response headers?

I saw this plugin which download files using Ajax and some other fallback techniques.

But since ajax download file feature is not supported in all browsers , he used a trick with Iframe. ( which is pretty easy to implement)

But one thing caught my eye :

He also added an option which tells you when the file has finished download.

He did it via cookie. He polls to see if the cookie via setInterval. as long as the cookie does not exist - the file wasn't finish download.( and when the cookie is present - the file has downloaded)

So the header for downloading a file is:

Content-Disposition: attachment; filename=Report0.pdf

And he added :

Set-Cookie: fileDownload=true; path=/

But then I thought - who said that set-cookie is called after the file has finish downloaded ?

Questions:

Looking at the actual headers :

1 - Does the browser digest each header according to the actual order of appearance ?

2 - Are there any headers which must appear prior to other headers ?

3 - Does the digest of each header - blocks the digest until current hedare digest is completed ? I mean : does the line content-disposition:attachment;filename=1.jpg prevents the browser from digesting the next header - until the filename=1.jpg is finished loading ?

I've also tried investigate it via fiddler but I didn't get any conclusion.( I mean how can I test it in fiddler ?)

You're right to be skeptical.

There's no requirement that a client wait until the response body is complete to evaluate the Set-Cookie header that preceded the body, and there's in fact good reason to believe that most browsers will set the cookie before the body is complete (since many web pages will look at document.cookie in JavaScript inside a HTML page).

In fact, I tested this (using a MeddlerScript you can see here: http://pastebin.com/SUwCFyxS) and found that IE, Chrome and Firefox all set the cookie before the download completes, and set the cookie even if the user hits "Cancel" on the download.

The HTTP specification includes the notion of a Trailer (which is a header that appears after the response body) but these are little used and not supported in many clients (e.g. WinINET/IE). If the client did support Trailers, the server could send the Set-Cookie header after the body which would mean that the client couldn't see it until the body finished downloading.