 |
| |
Hosting FAQ
 |
HTML 4 for the World Wide Web by Elisabeth Castro This well written Visual Quickstart guide is perfect for beginners to web design and covers everything from the most basic tags
such as text, images and links, to more complex topics such as tables, frames and forms. Also covered are advanced topics such as: Browser compatibility issues, Javascript and Cascading Style Sheets.
Highly recommended.
|
| |
When we talk about bandwidth we are referring to the data that is read from your website when anyone accesses it,
we use the terms bandwidth and data-transfer interchangeably.
The cost of transferring this data is the largest cost we incur in hosting your site, and consequently we have to
monitor its use very carefully. Every time anyone accesses a page of your
site on our servers, files from your site are transferred to the users web browser. Typically, a page with a few graphics (GIFs or JPEGs) will probably
require the transfer of about 30,000 bytes of data. Simple arithmetic shows that 1,000 hits to that page will generate 30,000,000 bytes of data transfer
which is about 30 MBytes (1 MByte = 1024*1024 bytes).
With our low cost hosting account, we allocate you 250 MBytes of data transfer per month, so the typical page from above can have just over
7,500 hits in a month before you will have reached your allocation. You can check the amount of data transfer you have used from the Website Settings
page of the control panel. This shows the usage for this month and the previous month if available.
Please read the next question about what happens if your site uses too much data transfer.
|
| |
The good news is that we have just increased the basic data transfer allocation for Low Cost Hosting from 100MBytes per month to 250 MBytes per month!
The bad news is that in order to do this we have had to become much stricter regarding over usage.
If you use more than your data transfer allowance for the month we will disable hosting of your website automatically until the start of the following month.
So it is important you ensure that additional data transfer is purchased if you come close to this limit.
But don't worry we will give you plenty of warning!
Our automated system will warn you by email when you reach 25, 50, 60, 70, 80, 90 and 100% of your allocation for the month.
Once you reach 100%, you will need to add additional data transfer. You can do this from our
upgrades page.
The additional data transfer allocation is more flexible than the basic allocation, please see the next question for an explaination.
|
| |
You can purchase additional data transfer for your domain from our upgrade page.
We now sell additional data transfer allocations in blocks of 500 MBytes at £8+VAT each.
This extra allocation isn't supplied on a per month or per year basis but is used
as your account needs it. If the data transfer for your site only goes above the 250MBytes per month occasionally then the extra allocation
will decrease slowly. If you go above your standard allocation more often then it will decrease more quickly.
For example if you purchase 500 MBytes of additional transfer and one month your transfer usage is 300 MBytes, then 50 MBytes (300 - 250) will be deducted
from the additional transfer allocation. This will leave you 450 MBytes of additional data transfer to use in future months if required.
You may notice that the control panel shows a total of 750 MBytes, this is the sum of the additional data transfer you have purchased, plus the
standard monthly amount we give you with the account.
Please note however that we cannot
provide refunds for unused data transfer allocations, and you must have an active hosting account to use any residual data transfer allocation
you might have.
|
| |
The web server log report available from the control panel is your friend.
The 'This month' option displays your logs from the beginning of the month, the Data transferred statistic tells you how much
data has been transferred for the month up until midnight last night, if this is above 250MBytes, then you probably need to upgrade
your data transfer allocation.
This figure may not agree exactly with the control panel website settings usage figure as they are sampled at different times of the day.
The 'Last 7 days' option is also useful because from it you can get a good idea of your average usage.
The Average data transferred per day statistic available at the top of the report gives you this information.
250MBytes per month is about 8 MBytes per day, and so if your average is above this then you may need to upgrade your data transfer allocation.
Probably the next most important statistic is the File Type Report.
This shows you the percentage of bytes transferred for each type of file on your site. In most cases this will
usually be .gif and .jpg files - ie: graphics/pictures. You should always try to optimise your graphics to be as small as possible.
If you are not sure how to do this, a good site to try is: NetMechanic.com. You should aim for a total page
size of about 30-40KBytes, this will mean your pages load quickly for visitors, and will minimise your data transfer usage.
The Request Report will show you the bytes used for each file accessed. This can be a long report if your site is quite large, but you should look
for files with high %bytes and try to reduce their size, or position them elsewhere on your site so that they are only accessed when necessary,
using thumbnails (small images that link to the larger image) is one way to do this.
To summarise:
- Check the web server access log report from the control panel
- Minimise/optimise the size of graphics and use thumbnails to link to large images.
- Keep your page sizes down to about 30-40KBytes if you can - use NetMechanic.com to check this.
|
| |
Here is the General Summary from a typical website:
(Figures in parentheses refer to the 7 days to 12-Sep-2001 10:42).
Successful requests: 7,432 (4,602)
Average successful requests per day: 675 (657)
Successful requests for pages: 643 (382)
Average successful requests for pages per day: 58 (54)
Distinct files requested: 506 (352)
Distinct hosts served: 336 (213)
Data transferred: 29.223 Mbytes (17.289 Mbytes)
Average data transferred per day: 2.657 Mbytes (2.469 Mbytes)
The main thing to note is that Requests refer to accesses to all types of file on your site. This includes graphics as well as pages.
Whereas requests for pages only refer to access to the pages of your site themselves and not to any graphic images they contain, this
is what is usually referred to as page 'hits'.
On average, most pages contain about 9-10 graphic images, so generally the total number of requests is usually about 10 times higher than the
number of requests for pages.
The above stats show total requests/requests for pages over the period the log was generated for, the last 7 days (in brackets) and an average
per day.
Distinct hosts served gives you an indication of how many different visitors your site has had. This is only an estimate, because it uses
the visitor's IP address to track them and many users will be accessing your site via a web proxy server
(AOL customers in particular use this), therefore the IP address can change with each access the visitor makes, or several visitors can appear
to have the same IP address.
|
| |
Simple: Data transfer costs money. If a host doesn't charge for data transfer then it is likely that, if you use too much, they will either:
disable your account without warning (look for hidden clauses in their terms and conditions regarding excessive use),
or limit access to your site (ie: make it very slow so that data transfer usage is reduced). Some hosts will even just terminate your account!
|
| |
Log into the Control Panel and set it to a known value from the Account Information page
(we don't have access to your FTP password so are unable to send it to you).
If you've lost your Control Panel password too, then click here.
|
| |
We now support Microsoft Frontpage 2000™ Server Extensions for Low Cost Hosting accounts.
This allows you to upload your site much more easily
using Frontpage. To enable support for Frontpage, simply visit the 'Change website settings' page of the
Control Panel, click the 'Manage Frontpage Extensions' link and then create an admin user
for your site to enable Frontpage support.
From Frontpage, you can publish your site by Clicking 'Publish Web...' from the file menu, and just entering:
http://yourdomainname.co.uk
You should then be prompted for the admin username and password which you entered in the step above.
This support is still experimental, if you have any problems, please contact us.
|
| | Any FTP client should work, but if you don't have one, you could try one of the following:
Neither is free, but you should be able to download a demo version in order to evaluate which one suits you best. Alternatively have a look at using Internet Explorer 5.5.
|
| | Here are the instructions to setup WS-FTP for FTP access to the domain yourdomain.com (replace this with your actual domain),
these settings should be the same or similar to most FTP clients (to view with images, click here):
- From the Sites Page, click New to add a new site.
- Enter the name of your site, this is for display purposes only, but for simplicity call it: ftp.yourdomain.com
- Next enter the ftp host name, this is ftp.yourdomain.com
- Now enter your logon information. Your username will probably be something like web1234 and password like GSG$1726ge, enter the actual
values you received in your order confirmation email. Remember to click the Save Password checkbox.
- You may also want to enter the start directory for WS-FTP to put the files into. To do this, select your site ftp.yourdomain.com from the
Sites Page, and click properties. Next click the Startup Tab and enter html/yourdomain.com into the Remote site folder
text field.
|
| | You normally get this error if you are trying to upload from behind a firewall. If that is the case, you should set your FTP client
to use Passive transfer mode. We believe that FrontPage 2000 doesn't support passive transfer mode at this time.
|
| | Yes, you can - providing you have version 5.5 or above. But we don't recommend using IE for uploading files, as we have found this
to be very temperamental. Ideally we recommend you use a proper FTP client such as
WS-FTP or CuteFTP.
To enable the FTP option in Internet Explorer 5.5 or above:
- Go to the Internet Explorer Tools Menu and select Internet options....
- Click the Advanced tab.
- Select the Enable folder view for FTP sites checkbox and click OK.
To access your site you simply enter: ftp://ftp.domainname/html/domainname/ into the browser address bar, and then enter your username and password when prompted. You should now be presented with an explorer view of your webspace which you can just drag and drop files into and out of.
|
| |
This is because you have not uploaded the files to the correct directory. The root directory of your FTP space is not the same as that for your
website. Files for your site www.domain.co.uk need to be put into the html/domain.co.uk directory (ie: when you log in via FTP
you will see a directory called html change to that, and then you will see a directory called domain.co.uk (or whatever your domain is called),
change to that and upload your files there.
Most FTP clients and web publishing software has a 'start' or 'server' directory setting. You should set this to html/domain.co.uk to save
you having to manually change directory each time you log on via FTP.
|
| | If you try to view your website without specifying a filename, our server will attempt to return the default page for your site, and if no default page file is found it will return a directory listing instead. To stop this happening you must have a file called index.html present in your webspace.
In addition to index.html our server look for default pages with the following names:
index.htm, index.shtml, Default.htm default.htm, index.php3, INDEX.htm, Index.htm, INDEX.html, Index.html, index.phtml, index.php, index.wml, Index.wml, home.htm, home.html, Home.htm, Home.html
The order the names are listed indicates the search order the server uses when looking for the default page.
|
| |
Sometimes your browser will cache (save) pages it visits and not redisplay them if they have been changed. This is usually fine for normal
site browsing, but not very useful if you are designing sites and testing changes you have made. If you are using Internet Explorer, the solution is
to:
- Go to the Tools|Internet options... menu
- Click the Settings... button in the Temporary Internet Files section
- Set the option for Check for newer versions of stored pages to Every visit to page
- Click Ok
This should ensure you always see the latest version of every page.
|
| |
Yes. So fred.gif isn't the same as Fred.gif or fred.GIF.
|
| |
This means they can have different access control too. For
example you could allow a user called Fred to have password-controlled access to
folders within www.fred.yourdomain but no access to password-controlled
folders within www.yourdomain.
All you need to do is make a directory in your domain directory with the name of the subdomain you want.
So if you want to use wap.yourdomain.com for instance, you would create a directory called wap in your html/yourdomain.com directory.
Your subdomain does not automatically need the www. prefix, if you want this, you will need to prefix your directory name with www., ie:
For www.fred.yourdomain.com, you would call the directory www.fred
Please note that subdomains function as separate sites to your root domain, and can have their own cgi-bin directory.
This means they can have different access control too. For
example you could allow a user called Fred to have password-controlled access to
folders within www.fred.yourdomain but no access to password-controlled
folders within www.yourdomain.
|
| | The path to Perl is: /usr/bin/perl
The path to sendmail is: /usr/lib/sendmail
The path to date is: /bin/date
The path to your cgi-bin is: /home/users/username/html/domain/cgi-bin
Where username is your username, and domain is the domain in question. So if you were user web1234 with domain fred.co.uk the path would be: /home/users/web1234/html/fred.co.uk/cgi-bin
Please note: This is a file path to your cgi-bin for use within cgi scripts and not the URL.
Where you need a URL (ie: in a FORM tag for instance) you would use:
/cgi-bin/scriptname or http://www.domainname/cgi-bin/scriptname
|
| |
When uploading scripts to your cgi-bin, please ensure you use Text or Ascii mode and not Binary mode. The reason for this is
that Perl will not run scripts that have carriage return characters in them, and text/ascii mode will automatically strip these characters
out of the file. This is the usual reason for getting a 500 error when trying to run scripts.
|
| |
No!
A shared webserver isn't the best place for testing scripts. Apart from being very anti-social if anything goes wrong, you don't have
access to the server error_log and determining the cause of problems can be very difficult.
Whilst we are normally very lenient people we will get tough with customers who deny services to other users because of badly written scripts.
The best way of testing and debugging scripts is to use a local webserver on your own machine, such as Microsoft's Personal Webserver.
|
| |
In general you shouldn't need to - our FTP server will set the correct permissions and ownership for your scripts. Altering these settings may
stop your scripts from running.
Our servers use suEXEC to enforce script security and scripts are
run as the user rather than as the webserver. suEXEC performs a number of tests on a script before it is run, and if any test fails the
script will be rejected with a 500 error.
From a user's point of view the relevent checks are:
- The script directory should have user and group ownership set to the user
- The script directory should only be writable by the user (ie: Must be 0755 or drwxr-xr-x)
- The script itself should have user and group ownership set to the user
- The script itself should only be writable by the user (ie: Must be 0755 or -rwxr-xr-x)
These checks ensure that one user cannot read or write to the private webspace owned by another user by the malicious use of cgi scripts.
|
| |
Yes you can. .htaccess files can be used to protect
your folders with a password. They can also be used to create
a custom error 404 page. Password files need to be edited
but since we do not provide telnet access to our servers
you will need to use a ready-made CGI program to manage your password
files. This one is good and it is free: http://www.cgi-factory.com/password/index.shtml.
Password protection: Outline –
(You can find a tutorial here)
- You will need the password-management program in your cgi-bin folder.
- You will need a plain ascii file called .htaccess in any folder
that you wish to protect. Note: the protection applies also to any sub-directors
beneath the protected folder.
- You will need to initialise the password protection system,
and maintain it from time to time as users are added/deleted.
Password protection: Specifics – (using .htpasswd)
- Ensure you upload scripts (eg: *.pl files) and datafiles (eg: .ht* files)
in ASCII mode.
- You do not need to change any permissions for any
scripts or files.
- You may not
be able to see the .htaccess file from your FTP client once
you have uploaded it, but most clients have a method of
accessing files by name.
- If you had to rename a file in your Windows95/98 environment
(eg: you had to name a file x.htaccess or .htaccess.txt
to keep MS explorer happy)
then remember to use your FTP facility to rename it back to .htaccess
Ensure the first line of the *.pl files (firsttime.pl
and htpasswd.pl) is #! /usr/bin/perl and not
#! /usr/local/bin/perl, but note that cfg.pl does not
have this line.
Place an empty .htpasswd in your domain root
directory – just upload a file called .htpasswd
containing a blank line.
Your .htaccess files you use to protect your folders should be
edited like this:
AuthName "My secure area"
AuthType Basic
AuthUserFile /home/users/username/html/yourdomain/.htpasswd
require valid-user
Edit the cfg.pl file as follows:
Set: ="/home/users/username/html/yourdomain/.htpasswd";
Set: ="someone\@yourdomain";
Notes: You need the \ before the @ symbol.
username in this context is the owner of yourdomain.
yourdomain is your domain or your subdomain.
Run the firsttime.pl from a web browser by
loading up the url with
http://www.yourdomain/cgi-bin/firsttime.pl
Once you've run it, you are advised to delete firsttime.pl from cgi-bin.
Run htpasswd.pl as required, to add/delete users, from a web browser by
loading up the url with
http://www.yourdomain/cgi-bin/htpasswd.pl
|
| |
Yes. This is also achieved by using an .htaccess
file. First create a '404 Error Page' of your own design and
call it error.htm. Next create (or edit) a file called .htaccess and add
the following:
ErrorDocument 404 http://www.yourdomain/error.htm
It is best to place these two files in the root directory of your
site. Any attempted access to a file that doesn't exist
anywhere in your site will bring up your custom error
document. You can see this in action if you click here: http://www.virtualnames.co.uk/anonexistentfile.htm
|
| |
- To include SSI commands in normal .html files, create or edit your .htaccess file and add the following line:
AddType text/x-server-parsed-html .html
|
| | Scripting is a complex subject, the links below should be a good starting point.
- CGI Scripts
- PHP 3
- MySQL
- .htaccess
|
| |
This is a list of books essential for web developers:
|
| | The webspace we supply is based on fast servers with many fewer accounts per server.
We also allow you to use CGI scripts which wouldn't be possible with most free webspace.
With web-hosting as with everything else, you get what you pay for. We have costed our hosting products carefully
to enable us to provide you with the best service and support at an affordable price, but still leaving us with
profit to invest in new equipment and facilities. We want to be around to continue supporting you in the years to come
and not be a six month wonder.
|
| |
This site is Copyright © 2000-2007, UKServers Ltd Reg: 3913296 Vat Reg: 572 7939 92
Terms and Conditions
|
|
