From a Windows Folder to a Live Linux Host
Four students build the school site on a Windows laptop in C:\schoolsite and check it by double-clicking the home page. Files include 'Home Page.html', 'Images/Logo.PNG', 'gallery/Photo 1.jpg' and 'Contact Us.html'. They upload with an FTP client to a Linux shared host, into public_html. Afterwards: typing the domain name shows a bare list of file names; choosing 'Home Page' gives 404 Not Found; the logo is broken on most pages, but one old page still shows it because the source still says file:///C:/schoolsite/Images/Logo.PNG; 'Photo 1.jpg' also 404s; the home page image is a 2.8 MB JPEG and the page gets about 500 visits a day; the contact form uses a form action of mailto:[email protected] and nothing arrives; the host offers a free SSL certificate that has not been installed, so browsers show 'Not secure'. The plan allows 20 GB of traffic per month.
1. Explain the cause of each symptom, one by one.
Read the worked answer
- Bare file list at the domain: there is no default document. The server looks for index.html (or index.htm/index.php) in public_html, does not find one, and falls back to listing the directory. 'Home Page.html' is not a default name.
- 404 on 'Home Page': the link and the file name must match exactly, including the space. A space in a URL must be written %20; hand-written links often omit it, and the server then looks for a different name.
- Logo broken on most pages, working on one: Linux file names are case-sensitive, so Logo.PNG and logo.png are two different files; the pages that work use the exact case. The one working page is a separate problem: file:///C:/schoolsite/... is an absolute path that exists only on that laptop, so it will break for every other visitor and on every other machine.
- 404 on 'Photo 1.jpg': same two causes combined - a space and a case or extension mismatch; the FTP log will show the name actually stored on the server.
- Form sends nothing: mailto opens the visitor's mail program and hands the message to it; the server does nothing. Visitors without a configured mail client see nothing happen at all.
- 'Not secure': the free certificate was never installed, so the site is served over plain HTTP.
2. Write the naming and folder conventions the team must adopt, and the pre-upload checklist that would have caught all of this.
Read the worked answer
Naming rules: all lowercase; no spaces (use hyphens); ASCII letters, digits, hyphen, underscore, dot only; short descriptive names; extension written once, correctly (.jpg, .png, .html); one index.html at the root acting as the default document. Folder rules: /index.html, /images, /css, /js, /gallery, with pages at the root. Every link and image is a relative path, resolved from the file that contains it - from /contact.html, images/logo.png means /images/logo.png, but from /gallery/index.html the same picture needs ../images/logo.png. No file:/// paths anywhere, ever. FTP upload in the mode that preserves files byte-for-byte (binary/auto), and confirm the transfer log shows success for every file. Pre-upload checklist:
- index.html exists at the root and the home page is reachable by the bare domain.
- All file names match all links, including case; run a link checker.
- No absolute or local paths remain (search the source for 'file:' and 'C:').
- Images resized and compressed before upload.
- Test the live URL in a fresh browser profile, not the local file, with the cache cleared.
- A custom 404 page exists and points back to the home page.
- Certificate installed, HTTPS forced, and no http:// links left in the page source.
3. Deal with the traffic limit, the contact form and the missing HTTPS: show the arithmetic and the fix for each.
Read the worked answer
Traffic. 2.8 MB x 500 visits = 1,400 MB, about 1.4 GB per day, so about 42 GB per month on a 20 GB plan - more than double, and the account will be suspended or throttled before the month ends. The picture is displayed at 400 x 250, so a 800 x 500 JPEG at quality 80 comes to roughly 100-150 kB, cutting the monthly total to about 2.3 GB and leaving room for everything else. Resize and compress before upload, keep a larger original only if someone actually needs it, and check the host's traffic report weekly.
Contact form. Replace mailto with a real handler: a small server-side script (PHP mail or an SMTP library), or a form service if the host does not allow sending mail. Add server-side validation, a required email field, a simple spam control, and a thank-you page so the sender knows it worked. Then send one test message and confirm it arrives, including in the spam folder.
HTTPS. Install the free certificate, force a redirect from http to https with a server rule, then search the page source for http:// references to images, fonts, scripts or iframes. Any one of them leaves the padlock broken or the content blocked as mixed content. Finally re-test the form over https, because a form posting to an http address is silently refused by current browsers.