URL losing port number in every page load

I'm currently taking care of a certain local website.

The default port has been changed, and can no longer be not included in the URL due to technical reasons, so now i'm using a certain port in the end of the IP at the URL, for example

100.100.100.100/website.aspx

no longer works (which accessed 80 by default)

100.100.100.100:81/website.aspx

with the port, works.

Works, though I can't click in any link or anything and the port vanishes (new page doesn't load). Then I keep the same URL and just include the port at the end of the IP and it works again, until I click in another link inside of it.

I have access to changing each link, but I guess that would not开发者_Python百科 be the right approach.

How should I procceed ?

--[EDIT]--

All URL's are already relative, and the whole issue of this question is not applicable in IE, this only happens on other browsers.

/website.aspx

What I said about changing each link would be something like

:10/website.aspx

But I really don't know..

--[EDIT]--

As requested:

<asp:HyperLink runat="server" Text="link" NavigateUrl="~/folder/folder/page.aspx" />

If you type:

http://1.2.3.4/website.asp

That is equivalent to

http://1.2.3.4:80/website.asp

If you need to specify a different port you must include it explicitly in the URL.

Option 1 If all your links are of the form

http://1.2.3.4/website.asp

You'll need to change them to

http://1.2.3.4:10/website.asp

Option 2

Option 2 is to change all links to be relative so instead of having:

http://1.2.3.4/anotherpage.asp

You change it to just

/anotherpage.asp

The browser will then use the same IP and port number for each request.

Option 2 is preferred since it makes sites robust against exactly these types of moves.

Try to add a Binding in the IIS. (I assume you are using IIS for this)

Edit: I assume that you have set a binding to port 10. Add an alternative binding without port (if that is possible. if not, add a binding for port 80) I hope this helps.

Internet Explorer doesn't like addresses whose first colon isn't part of the scheme definition ("http://", or "https://"). You're starting your links with "http://" (or "https://")? If not, it might contribute to the problems you're having.