Secure sites... and the theory of relativity

[Ron Weldy]

In the past, I have always handled secure sections of websites using IIS.
You put the files you want to transfer data securely in a folder and you
indicate that in IIS. If you really need to force the url, then I have also
encountered code that picks up the current domain or server and then
concatenates the url accordingly.

Now, I have this site that someone else set up and they have hard-coded the
links with the https prefix to force them to be handled securely (not to
mention some other plain ol' links as well). Why would they not setup secure
directories? I can't remember if IIS prevents you from running the pages in
a non-secure mode. Of course, the other major problem with this in that it's
a pain in the *** if you're using a test server. Anyone know why someone
would do this? Is there some search engine penalty if you don't hard code
full urls in html? Another interesting thing is that this is buried in
asp.net controls, which I don't even expose links, so I really don't
understand why that is not done using relative links, unless there is some
goofy-ness with these controls living in the bin folder. At any rate, I
usually use relative pathing myself just to keep my sanity when testing.

All opinions are welcome, before I set about trying to correct this mess!

 

[Ken Schaefer]

Might be worth seeing if you can contact the developer and get their
reasons. I see no technical reason why you need to code the URLs using
https:// except where one is switching from a http:// site over to a
https:// site

Cheers
Ken

 

[Kristofer Gafvert]

I once asked a developer why they used absolute oaths instead of relative
paths. They said that was the only thing that worked. Obviously they did
not know how to use relative paths...

As Ken says, you need to use it when you change over to https from http.