<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Maybe I am seing oversimplified things here, but it seems to me the question does not require all the effort everyone amazingly puts in here.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">If you want to catch HTTP requests separate from HTTPS requests, make 2 server blocks, as Avraham suggested.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">You can then redirect all requests coming to the HTTP block to the same URI with the HTTPS scheme (301, 302, 303, 307... have it your way!). There is not constraint regarding HTTP pages loading HTTPS content (while reverse is true).<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">I am making the assumption the request to a HTTP resource in the HTTPS page will be made, here. If the browser prevents them because they are seen as insecure, there little to nothing you can do about it. Stupid webpage service cannot be fixed on the remote side.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Of course, the client browser embedding the content will need to be clever enough to follow redirects on included resources, which is I think the case of any standard use-case.<br></div><div class="gmail_extra"><br><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">​Am I missing something there?​</div><div><div class="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Wed, Nov 11, 2015 at 2:32 PM, Francis Daly <span dir="ltr"><<a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Nov 11, 2015 at 03:25:11PM +0500, shahzaib shahzaib wrote:<br>
<br>
Hi there,<br>
<span class=""><br>
> Actually we've video sharing website from where people embed http/https<br>
> links to there websites. Now the problem is, some of the HTTPS  websites<br>
> have embedded HTTP URL links from our website instead of HTTPS due to which<br>
> the code is unable to execute on their HTTPS website because it is making<br>
> call from https -> http which is wrong.<br>
<br>
</span>Before you put too much time into building the solution, can you do a<br>
quick test to confirm that it can work?<br>
<br>
As in:<br>
<br>
* on a https site, include a link to http on your server to one particular<br>
url that you control.<br>
* in your config, redirect that one url to something https on your site<br>
* for that https request, return the response that you want<br>
<br>
When you do that -- does it work?<br>
<br>
As in: do you know that the client (browser) that you care about, will<br>
access your http url and accept the https redirection and then make use<br>
of the code that you return over that https link?<br>
<br>
Because if that does not work, then it does not matter what else you do.<br>
<span class=""><br>
> So we're thinking to have some condition in place that if the request for<br>
> HTTP embedded link comes from any HTTPS domain , nginx will detect that<br>
> source $scheme and redirect that request to HTTPS.<br>
<br>
</span>You cannot reliably detect where the link came from.<br>
<br>
If you are willing to accept unreliably detecting where the link came<br>
from, knowing that some innocent cases and some malicious cases will be<br>
handled wrongly, then you can just examine $http_referer.<br>
<br>
If it starts with "https://", then probably the link was on a https site.<br>
<br>
If it starts with "http://", then probably the link was on a http site.<br>
<br>
If it is blank, then probably the link was on a https site and it is<br>
accessing your http site.<br>
<br>
Each "probably" is because the Referer header is set to whatever the<br>
browser wants. Some browsers lie. Some browsers omit it always. Some<br>
browsers set it to a non-default value because that's what the user<br>
configured it to do. Other possibilities exist.<br>
<span class="HOEnZb"><font color="#888888"><br>
        f<br>
--<br>
Francis Daly        <a href="mailto:francis@daoine.org">francis@daoine.org</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div></div>