Https pages in websites not running on port 80

Question

User1773436720 posted

Hi,

I have a question about redirects and port numbers.

I have a web forms application which, for testing purposes, needs to be on any port but 80.(Real company site has to remain on 80 until we thoroughly test the environment). However, I also have pages in the site that after login need to be encrypted, hence I want them to run on HTTPS over port 443. Every thing works fine while in the dev environment and running without a port number appended. But as soon as I publish it to the web server and bind it to another port, the HTTPS pages get blocked.

For example, These pages work:

http:\\mysite.com, and http:\\mysite.com\home, and https:\\mysite.com\admin, yada yada

In the following urls, the Https  pages are blocked:

http:\\mysite.com:85, and http:\\mysite.com:85\home, and https:\\mysite.com:85\admin, yada yada

So how can I check the protocol(or the port) and change the url adddresses so my secured pages work? Can I remove the port number thru code and still get to my pages?

Does this question make sense?(And, 'NO' no points for answering yes or no, lol) 

Answer 1

User753101303 posted

Hi,

AFAIK you have to use a distinct port number for http and https (it seems you use port 85 for both now). What if using a different port? Or could it be a firewall issue? Rather than "blocked" try to always describe accurately what happens.

Finaly make sure 80 and 443 really can't be used.

Answer 2

User1773436720 posted

TY PatriceSE for the reply.

'(it seems you use port 85 for both now).'  Yes that is the problem, https in the company router is mapped to port 443(Normal) and our current company web site(http) is mapped to port 80.

For internal testing purposes I am putting the new site on another port, lets say port 85. This means that we have to enter the port number at the end of the sites' url.(ex. http:\\mysite.com:85)  The standard non-secure pages work fine on that port.  

When I redirect to secure pages in the application, the browser 'automatically' redirects to 443. However, I still have the ':85' in the URL. This breaks the app.

'(try to always describe accurately what happens)'...I get a 'ERR_SSL_PROTOCOL_ERROR' in the webpage. I am thinking it is because the https url still has the ':85' in it.

So I'm wondering how to handle this. When I put the site on port 80, no port number is required in the url. In this situation both http and https pages work as expected.

Answer 3

User753101303 posted

Ah got it.

So my understanding is that the redirection logic is inside your app. We would need to better understand your current approach but more likely you only paid attention to the "http" and "https" portion ignoring the port number. If you have that in a single function it should be easy to add the logic needed to fix this shortcoming.

For now my preference would be likely :
- to see first if there is a valid reason for not using 80 and 443. you code would just work then.
- to see if it would be better to just encrypt everything (it might be not a problem if you have just few pages) - then you don't have any more to ever change the protocol/port
- to fix the code logic to take into account for example a port number settings
- to use a url rewriting rule such as here : http://stackoverflow.com/questions/13189505/url-rewrite-redirect-to-different-port-and-changing-url-using-map

#4 might be quicker than changing your code though if you fix your code you'll have just the right port to start with rather than having a wrong port number and having to add a rewriting rule to fix this wrong port number. Or do that and fix your code later.

For #3, not sure what you are doing. You perhaps have a function that returns the new "root" (ie http/https plus the host name plus the port ?) and then append the destination on the site ? So more likely rather than just keeping the port as you perhaps do now, you should force the port depending on using http or https (maybe having those port numbers as application settings).

 Edit : #1  might be because you are using the same host name for this new version? If so you could use another host name (ie having yourcompany.com and new-yourcompany.com for example rather company.com and company.com:85.