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.

If you want to catch HTTP requests separate from HTTPS requests, make 2
server blocks, as Avraham suggested.
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).
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.

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.

​Am I missing something there?​
---
*B. R.*

On Wed, Nov 11, 2015 at 2:32 PM, Francis Daly <francis@daoine.org> wrote:

> On Wed, Nov 11, 2015 at 03:25:11PM +0500, shahzaib shahzaib wrote:
>
> Hi there,
>
> > Actually we've video sharing website from where people embed http/https
> > links to there websites. Now the problem is, some of the HTTPS websites
> > have embedded HTTP URL links from our website instead of HTTPS due to
> which
> > the code is unable to execute on their HTTPS website because it is making
> > call from https -> http which is wrong.
>
> Before you put too much time into building the solution, can you do a
> quick test to confirm that it can work?
>
> As in:
>
> * on a https site, include a link to http on your server to one particular
> url that you control.
> * in your config, redirect that one url to something https on your site
> * for that https request, return the response that you want
>
> When you do that -- does it work?
>
> As in: do you know that the client (browser) that you care about, will
> access your http url and accept the https redirection and then make use
> of the code that you return over that https link?
>
> Because if that does not work, then it does not matter what else you do.
>
> > So we're thinking to have some condition in place that if the request for
> > HTTP embedded link comes from any HTTPS domain , nginx will detect that
> > source $scheme and redirect that request to HTTPS.
>
> You cannot reliably detect where the link came from.
>
> If you are willing to accept unreliably detecting where the link came
> from, knowing that some innocent cases and some malicious cases will be
> handled wrongly, then you can just examine $http_referer.
>
> If it starts with "https://", then probably the link was on a https site.
>
> If it starts with "http://", then probably the link was on a http site.
>
> If it is blank, then probably the link was on a https site and it is
> accessing your http site.
>
> Each "probably" is because the Referer header is set to whatever the
> browser wants. Some browsers lie. Some browsers omit it always. Some
> browsers set it to a non-default value because that's what the user
> configured it to do. Other possibilities exist.
>
> f
> --
> Francis Daly francis@daoine.org
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx