Redirect request based on source $scheme !!

[shahzaib shahzaib]

>>you can create separate server blocks for each domain
I think issue will still persist. Say https://ad.domain.com makes static
call to http://ourdomain.com , it'll end up with conflicted scheme i.e
https -> http. We can't force http to https as well because it'll break
static calls from http -> http.

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. The number of these malformed links
are huge and there's no way that those users can manually correct
the embedded links by editing http to https and vice versa).

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.

On Wed, Nov 11, 2015 at 3:10 PM, Avraham Serour <tovmeod at gmail.com> wrote:

> you can create separate server blocks for each domain
>
> On Wed, Nov 11, 2015 at 11:36 AM, shahzaib shahzaib <shahzaib.cb at gmail.com
> > wrote:
>
>> Hi,
>>
>>    Is there a way we can serve $scheme (HTTP/HTTPS) based on source
>> request ? Such as :
>>
>> if https://ad.domain.com --> sends request to http://ourdomain.com (as
>> it'll fail due to cross  $scheme conflict)
>>
>> So http://ourdomain.com will check that the request invoked using https
>> $scheme and it'll redirect http://ourdomain.com to https://ourdomain.com
>> for that particular ad.domain.com.
>>
>> ---------------------------------------------------------
>>
>> Is that possible guys ?
>>
>> Thanks in Advance !
>>
>> Regards.
>> Shahzaib
>>
>>
>> Need to send me private email? I use Virtru
>> <https://www.virtru.com/how-it-works/?utm_medium=Email&utm_source=Plugin%20Users&utm_campaign=Footer>.
>>
>>
>> _______________________________________________
>> 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/35eb3ef8/attachment.html>