Http Response Header Execution Order?

I saw this plugin that uploads files using Ajax and some other backup methods.

But since the ajax file upload function is not supported in all browsers, it used the Iframe trick. (which is pretty easy to implement)

But one thing caught my attention:

He also added a parameter that tells you when the file is finished to download.

He did this through a cookie . It polls if there is a cookie through setInterval . while the cookie does not exist, the file has not been downloaded. (and when a cookie is present - the file is loaded)

So, the header to download the file:

Content-Disposition: attachment; filename=Report0.pdf

And he added:

Set-Cookie: fileDownload=true; path=/

But then I thought - who said that the set-cookie is called after , the file is already loaded?

Questions:

Looking at the actual headers:

enter image description here

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

2 - Are there headings that should appear before for other headings?

3 - Is there a digest for each header - blocks the digest until the current hedare collection finishes? I mean: does the line content-disposition:attachment;filename=1.jpg not allow the browser to digest the next header - until the download completes filename=1.jpg ?

nb

I also tried to investigate it with the help of a violinist, but I had no conclusion. (I mean, how can I check it in the violinist?)

+1
source share
1 answer

You are right to be skeptical.

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

In fact, I tested this (using MeddlerScript, you can see here: http://pastebin.com/SUwCFyxS ) and found that IE, Chrome and Firefox all set a cookie before the download was complete and set a cookie, even if the user clicks β€œCancel” while loading.

The HTTP specification includes the concept of Trailer (which is the header that appears after the response body), but they are not used much and are not supported by many clients (for example, WinINET / IE). If the client really supported the trailers, the server could send the Set-Cookie header after the body, which would mean that the client could not see it until the body finished loading.

+2
source

All Articles