Salesforce.com – This request has been blocked; the content must be served over HTTPS.

[et_pb_section fb_built=”1″ admin_label=”section” _builder_version=”3.22″][et_pb_row admin_label=”row” _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text admin_label=”Text” _builder_version=”3.27.4″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”]

While working on an integration one of my friend was having an wired issue (This request has been blocked error). No clue why the code was behaving in this way. Without wasting time let me go to the error and details about it.

The issue :

The integration pattern was in a way that we had to show the returned response in an inline page where we wanted to view the response. Basically the response was a PDF file and we wanted to preview the PDF in the salesforce page. Sounds simple enough isn’t it ?

But the real problem is we could preview the PDF in Internet Explorer and Firefox but not in Chrome. We had the adobe Reader installed and we could view the data everywhere else but not just Chrome.

The code sample of the issue :

Root Cause :

The reason behind this behavior was the protocol used for the integration end point at the source. In this case the source was 3rd party and was something like http://test.getthekt.com?pdfid=atth4456yugetthekt. Here was the issue at http. Http not secure as we all know. But we were firing the request from an https client ( Salesforce.com in this case) and were getting http response back. So the browsers were little worried. They thought there is something happening. They got confused as both types of protocols were used. So browsers started blocking this response.

Resolution :

To resolve this issue, we have various options. Like changing the 3rd party protocol from http to https. Which is pretty simple correct !😀. Ah you know I am just kidding. That’s the last option actually. The second option we have is doing some configuration at client side, at the browser level, so that we can ignore this exception and let the browser accept the response that it received. Another option could be convert the requestor to http so that both the protocols match and there will not be any issues.

Sample code which will reproduce this issue:

 

Here are some browser specific quick fixes.

For Internet Explorer :

In Internet Explorer you will get a popup as below to ignore this message and it will ignore the error. Your functionality works fine.

After accepting the message.

 

For Firefox :

Firefox as well will give you an option to ignore this error.

 

Follow the below steps to allow firefox to ignore this message.

 

The error is gone.

 

For Chrome :

Chrome as well gives you an option to ignore this error. You can see the actual error by opening the Developer tools for the Chrome browser.

 

 

Click on Load Unsafe Scripts.

 

The error is ignored and PDF(The response) is rendered.

This solution is also specified in Google support site.

https://support.google.com/chrome/answer/1342714

 

These are temporary fixes as every time you open the browser you will have to allow the browser to ignore them.

Also we have another way to handle this in salesforce, where we can expose the response to force.com site, which is usually a http endpoint. In this case it will work without any intervention required.

 

 

You might still need to add a Chrome Extension to render the PDF. Specifically if you are rendering PDF documents in Chrome.

 

fooooh… It was a long article ..

But I really hope it will help someone out there in need. If you like this article please click on follow at the bottom to keep getting articles in your inbox.

Keep reading and sharing …. GetTheKt and share it 🙂

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]