Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SSL URL confusion

Status
Not open for further replies.

audiopro

Programmer
Apr 1, 2004
3,165
0
0
GB
My experience with SSL on shared hosting is quite limited but after using 3 separate installations for a number of years, I am more than a little confused by the settings I have been given for a site, recently ported to a new server.

At first, Perl scripts in the CGI-BIN, wouldn't execute, instead they just displayed the source code.
The ISP said there was something wrong with the MIME settings and after some tweaking, Perl scripts would execute.

The problem I have now is that no relative links, from the cgi-bin will work. Full URLs to Dirs outside the CGI-BIN will work for images etc but calls to include templates are met with a blank screen.

So to the questions
My old SSL had links like this
Code:
[URL unfurl="true"]https://SecureServerName/MyDomain.co.uk/[/URL][b]cgi-bin[/b]/PerlScript.pl"

The new one requires the CGI-BIN Dir before the domain name
Code:
[URL unfurl="true"]https://SecureServerName/[/URL][b]cgi-bin[/b]/MyDomain.co.uk/PerlScript.pl"

What is the normal arrangement for this and could this arrangement be affecting relative links?
Do relative links normally work on all SSL installations or have I previously just been lucky?

Keith
 
I run SSL all the time with Perl, but I have a go daddy certificate installed on the IIS webserver.

I have used shared SSL before, but it was some time ago, so my memory is fuzzy.

I think because of the way the shared SSL works, it requires a particular URL that the SSL is encrypting, so yes relative links from your normal domain won't work in this situation.

IIRC, as there is only one SSL on a shared domain, your sited is mapped as a path on the SSL domain, so you might need to modify your templating to include a special var that stores the URL for HTTPS....

I used to use BAREWORD global constants for this in my apps, which get exported...

Code:
use constant URL_TO_HTTPS => "[URL unfurl="true"]https://www.the_SSL_domain.com/myDomainName";[/URL] # URL to HTTPS folder

Then using HTML::Template in my Perl script...

Code:
    # Add variables to Template
    $template->param( 'url_to_https' => URL_TO_HTTPS);

And then you can use in your HTML templates...
Code:
<a href="<tmpl_var name='url_to_https'>/cgi-bin/my_perl_script.pl">I'm a hyperlink</a>

I stayed with these global location identifiers for many years when using shared Hosting / SSL, because the buggers kept moving things, and so all I had to do was update the globals module with the new paths and everything just worked again!

for what you provided it would be something like
Code:
use constant URL_TO_HTTPS_BIN => "[URL unfurl="true"]https://SecureServerName/cgi-bin/MyDomain.co.uk/";[/URL] # URL to HTTPS CGI-BIN folder

You get the idea!

Though to be honest, how much do they charge for a domain SSL cert? I'm sure you could get one for your site for less than £100.00 PA from Go Daddy?




"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music
 
The cost of the SSL cert is just less than £100 but not my responsibility as it is on a client's website.

The relative links are within the SSL between scripts in the cgi-bin and static data files within sub directories of the cgi-bin. I have never had a problem before with this but despite the ISP's protests, I still maintain they have messed up the installation in some way.

I am getting to the end of my tether with this ISP as I do not like being treated like an idiot.

Let me ask you a question - what would this print to screen if placed in the html section of the website?
Code:
<html>
 <head>
 </head>
 <body>
£
</body>
 </html>

It would print a '£' wouldn't it?

not on this server it just prints a hollow square box yet the ISP say that it is working fine.

Keith
 
well it seems it could be the UTF8 encoding.

To be honest I never use a GBP sign as technically it's invalid mark-up (according to W3C).

You should use

But I hear you with shared hosting, it can be a nightmare when it goes wrong. I moved host several times when using shared hosting because of this and as you say, the idiots in support treat you like the idiot causing the problem.

However, using my path mapping globals meant I could move hosting company when ever I liked and it just required me to update the path globals for it to all work again.

Since running my own webserver all my hosting woes have melted away!



"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music
 
I am aware of the &pound; coding and this is the advice which the ISP have come up with after a week of 'support tennis'.

The £ sign has been available in the UTF-8 character set since I first learnt to plug a monitor in and this is the first time I have needed to use any tricks and dodges to make the currency symbol of my country to display on a web page.
All the other servers from the same ISP display the char without any issues so I am still sticking to my guns that the server is incorrectly set up.



Keith
 
For sure Keith, it's not a game stopper, it's just best practice.

If a pound isn't rendering correctly in static HTML on their hosting then their is something configured wrong somewhere!

Is it possible they have something wrongly configured that is PHP parsing or a.n.other (SSI for example) for all pages and the parser is corrupting the encoding?

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music
 
Not sure what is wrong with the server.
All I know is my client pays for the server and they, as an ISP, should supply a fully working platform on which to load the client's websites and have it function properly.
All this worked fine on an old server until one day, sendmail just stopped working.
The ISP said they didn't change anything.
I think it happened the day the cow jumped over the moon.
This is not a long term problem because when the current hosting package expires, the sites are being moved to an ISP where the techs actually know what they are doing.


Keith
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top