I would like to first start off that last week’s problem of not having the automatic redirection working in Firefox was actually my own mistake without even realizing it. Basically, the CORS protocol should only take place for cross site requests, for example if a client application that is being served from www.domainA.com makes a request to www.domainB.com , then it first have to make a preflight request to determine whether or not it is allowed access to domainB’s resources, as well as what HTTP methods and headers are allowed. This is done using an OPTIONS request. This is not needed if the client makes a request to the server of the same origin. According to MDN, having the same origin means having the same protocol, port (if any) as well as the host.
The way I have been doing my development process so far for the Vuejs application is that I have the HTML and JavaScript files being served from a mock development server, i.e the webpack-dev-server module, just to ease my development process or so I thought. Hence, it seemed like the client and the server application are of different origins. However, in the actual production of the application, the client and server application would be hosted in the same server, therefore no CORS protocol should take place between client and server. After having that issue pointed out by Dr Shawn, I made the client side files be served from the server application and now they are of the same origin. Automatic redirection is not an issue anymore.
So the reason why it didn’t work before was because the CORS protocol original specification mentioned that HTTP status codes other than the 2XX range are considered to be errors, hence automatic redirection is not allowed in other words. It was only until about 2 years ago when that has changed, and browsers like Chrome and Edge have already adopted the new standard, but for some reason Firefox hasn’t. You can find a discussion of it right here. All in all, the CORS protocol should only take place between the browser and the server running in the board.
Alright, with that now out of the way, I could easily implement the whole firmware download procedure. Also, I changed some things that is different from the initial plan. The plan was to send the request to the server, calculate the HOTP value and increment the counter, then send a 307 status to that the browser can redirect the same request to the server running in the board. The PUT request is where the firmware would be downloaded as a bitstream from the server then redirect it to the board. The HEAD request is sent directly to the server in the board, which will compute a MD5 checksum of its new firmware and the browser could compare that MD5 checksum with the checksum it got earlier or computed before.
The initial MD5 checksum could be done on the application’s server and put it in a Content-MD5 header in the response, or it could also be done on the browser itself. However, that would mean that the client application would first have to grab the bitstream and calculate its MD5 checksum or grab the Content-MD5 header value and temporarily store it somewhere. We thought axios interceptors would be able to intercept the response before the redirection happens, but then it is only able to intercept the response after the redirection, which ends up being the response from the board’s server instead. So now the PUT operation is done manually instead of an automatic redirection.
Now it just comes down to testing it with the actual board. There are a few things that needed to be changed on the board’s side in regards to the CORS preflight request in order to make it work. The requests were able to reach the server in the board, but there were some issues transmitting the bitstream to the board which we have not yet resolved. Dr Shawn made a sample bitstream file earlier for me to test out with first. So until then, I would test other things out through a PHP development server which attempts to emulate the server running in the board. More updates to come in the following weeks.
0 Comments