There was an issue that I could not figure out what was going on until last minute of the release. I decided to write about it as the solution was very simple,it is a hint given to me by a genius, my fellow colleague.
Let me describe the issue first.
I wanted to generate a PDF in the browser and used Pdf make, which is an awesome javascript library, works well with data tables. There was a requirement to add the logo/image to the page header. The logo is already loaded on the page as and the image was stored in S3. When a user prints the PDF, it will download the image via ajax call(then cache it). So it was a simple implementation what I had to implement the ajax call and convert to image data URL and pass it to the pdfmake( Currently, pdf make only accepts base64 image dataurls as it is not asynchronous PDF generation ). Every time I try to print, Chrome throws "No 'Access-Control-Allow-Origin' header is present on the requested resource".
What could be the reason?.
It turns out that Chrome will cache the response for the performance if the same resource is requested multiple times. When the page loads it does not send Origin HTTP header and requests the image from S3 and assign to HTML image source. Once the user prints PDF then it will use the cached response. But the second request is an ajax call and it expects Allow Origin: * in the response header and it fails 😡. And Google won't fix it.
In the Amazon side, S3 sends the Allow Origin response only if it receives the Origin header in the request. Obviously, the first Image rendering call won't send the Origin header. There is no way to add the response headers in S3 side unless you use cloud front as a proxy. Amazon won't change their implementation in S3 as well.
After doing some research and trying a number of alternatives, my friend gave me a hint to fool the browser. For ajax call, we changed the URL to https://s3.fake.image.url.com?ver=foolme. Chrome suddenly decided not to cache it and it will request from the server again.
So everyone was happy !!!.
Let me describe the issue first.
I wanted to generate a PDF in the browser and used Pdf make, which is an awesome javascript library, works well with data tables. There was a requirement to add the logo/image to the page header. The logo is already loaded on the page as and the image was stored in S3. When a user prints the PDF, it will download the image via ajax call(then cache it). So it was a simple implementation what I had to implement the ajax call and convert to image data URL and pass it to the pdfmake( Currently, pdf make only accepts base64 image dataurls as it is not asynchronous PDF generation ). Every time I try to print, Chrome throws "No 'Access-Control-Allow-Origin' header is present on the requested resource".
What could be the reason?.
It turns out that Chrome will cache the response for the performance if the same resource is requested multiple times. When the page loads it does not send Origin HTTP header and requests the image from S3 and assign to HTML image source. Once the user prints PDF then it will use the cached response. But the second request is an ajax call and it expects Allow Origin: * in the response header and it fails 😡. And Google won't fix it.
In the Amazon side, S3 sends the Allow Origin response only if it receives the Origin header in the request. Obviously, the first Image rendering call won't send the Origin header. There is no way to add the response headers in S3 side unless you use cloud front as a proxy. Amazon won't change their implementation in S3 as well.
After doing some research and trying a number of alternatives, my friend gave me a hint to fool the browser. For ajax call, we changed the URL to https://s3.fake.image.url.com?ver=foolme. Chrome suddenly decided not to cache it and it will request from the server again.
So everyone was happy !!!.
Comments