Redirect request based on source $scheme !!

[shahzaib shahzaib]

>>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).

B.R yes, we've decided to go with this strategy as well. I think that
should do the job, we just overlooked things and made it more complex.

Thanks for help and suggestion guys, i'll update about the results. :)

Regards.
Shahzaib

On Wed, Nov 11, 2015 at 7:13 PM, B.R. <reallfqq-nginx at yahoo.fr> wrote:

> 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 at 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 at daoine.org
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20151111/f5517736/attachment.html>