§-Syllabus dot point

NSWSoftware EngineeringSyllabus dot point

Inquiry Question 1: How are secure web applications developed?

Explain the HTTP protocol, including request methods, status codes and headers, and the role of HTTPS in securing web traffic

A focused answer to the HSC Software Engineering Module 2 dot point on HTTP. Request methods, status codes, headers, the role of HTTPS and TLS, the worked example, and the traps markers look for.

Generated by Claude Opus 4.85 min answerUpdated 2026-06-18

Reviewed by: AI editorial process; not yet individually human-reviewed

Have a quick question? Jump to the Q&A page

In plain English

HTTP is the language a web browser and a web server use to have a conversation. Every exchange follows the same shape as ordering at a counter: you (the browser) send a request that says what you want and how ("GET me the menu", "POST this order"), and the person behind the counter (the server) sends back a response that says what happened, using a short code everyone understands, like a barista calling "ready" (200 OK) or "sorry, we're out" (404 Not Found). HTTPS is that same conversation held inside a sealed, tamper-evident envelope instead of shouted across the room: a stranger nearby can see that a conversation is happening, but not read the words (encryption), cannot swap out the note inside without it being obvious (integrity), and can check the envelope's wax seal to be sure they are really talking to the shop they think they are, not an impostor standing in for it (server authentication).

What this dot point is asking

NESA wants you to know the structure of HTTP requests and responses, the standard methods and status codes, the role of headers, and how HTTPS layers encryption and identity on top.

The answer

Anatomy of an HTTP request

Every HTTP request starts with a request line that names the method and path, then carries any number of headers, then optionally a body. The example below shows a POST request submitting a JSON payload.

POST /api/comments HTTP/1.1
Host: blog.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Content-Type: application/json
Content-Length: 32

{"article_id": 7, "text": "Hi"}

Method: POST
Path: /api/comments
Version: HTTP/1.1 (or HTTP/2, HTTP/3)
Headers: key-value metadata
Body: optional, present for POST/PUT/PATCH

Anatomy of an HTTP response

Every HTTP response starts with a status line that names the version, status code and a short reason phrase, then headers, then optionally a body. The example below shows a successful resource creation that returns the new resource as JSON.

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/comments/91
Content-Length: 27

{"id": 91, "status": "ok"}

Status code: 201
Status text: Created
Headers: response metadata
Body: optional, contains the resource representation

Methods

Method	Purpose	Idempotent	Safe
GET	Retrieve	Yes	Yes
POST	Create / submit	No	No
PUT	Replace	Yes	No
PATCH	Partial update	No	No
DELETE	Remove	Yes	No
HEAD	Like GET but headers only	Yes	Yes
OPTIONS	Inspect supported methods	Yes	Yes

Idempotent means calling the request many times has the same effect as calling it once. Safe means the request does not change server state.

Status codes

1xx: informational (rarely seen).
2xx: success. 200 OK, 201 Created, 204 No Content.
3xx: redirect. 301 Moved Permanently, 302 Found, 304 Not Modified.
4xx: client error. 400, 401, 403, 404, 429 Too Many Requests.
5xx: server error. 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.

Headers

Headers carry metadata. Useful examples:

Content-Type: application/json describes the body format.
Authorization: Bearer ... carries an authentication token.
Cache-Control: no-store instructs caches not to retain the response.
Set-Cookie: session=... issues a cookie to the browser.
Strict-Transport-Security: max-age=31536000 forces future requests to use HTTPS.

HTTPS

HTTPS is HTTP carried over TLS. It provides three guarantees:

Confidentiality: traffic is encrypted so eavesdroppers see only ciphertext.
Integrity: tampering with the request or response is detected.
Server authentication: the certificate proves the browser is talking to the legitimate server (not a man-in-the-middle).

The TLS handshake combines asymmetric and symmetric encryption: asymmetric for key exchange and certificate verification, symmetric (AES) for the bulk session traffic.

A worked example

A Python script using requests:

import requests

response = requests.post(
    "https://api.example.com/comments",
    headers={
        "Authorization": "Bearer eyJhbGciOiJIUzI1NiIs...",
        "Content-Type": "application/json",
    },
    json={"article_id": 7, "text": "Hi"},
)

print(response.status_code)  # 201
print(response.headers["Content-Type"])  # application/json
print(response.json())  # {"id": 91, "status": "ok"}

requests handles the TLS handshake automatically. The HTTP wire format - method, path, headers, body - is what is actually sent across the network.

Exam-style practice questions

Practice questions written in the style of NESA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.

2025 HSC5 marksDescribe the structure of an HTTP request and response. Identify two request methods and two status codes, and explain the role of HTTPS in web traffic.

Show worked answer →

An HTTP request has a method (GET, POST, PUT, DELETE), a path (/api/users/42), a version (HTTP/1.1), headers (key-value metadata: Host, Accept, Authorization), and an optional body (for POST/PUT requests).

An HTTP response has a version, a status code with text (200 OK, 404 Not Found), headers (Content-Type, Cache-Control), and a body containing the resource (HTML, JSON, an image).

Methods (any two):

GET: retrieve a resource. Safe, idempotent. No request body.
POST: create a resource or submit data. Not idempotent.
PUT: replace a resource. Idempotent.
DELETE: remove a resource. Idempotent.

Status codes (any two):

200 OK: success.
201 Created: success, new resource created.
400 Bad Request: client sent malformed input.
401 Unauthorized: authentication missing or invalid.
403 Forbidden: authenticated but not allowed.
404 Not Found: resource does not exist.
500 Internal Server Error: a bug on the server.

HTTPS is HTTP over TLS (Transport Layer Security). It encrypts the request and response, verifies the server's identity via a digital certificate, and protects against eavesdropping and tampering. Browsers display a padlock when HTTPS is active and warn or block plain HTTP for sensitive sites.

Markers reward correct structure of both message types, valid methods and codes (with grouping by 2xx success, 4xx client error, 5xx server error), and identifying the three properties HTTPS provides: confidentiality, integrity, server authentication.

Practice questions

Original practice questions graded from foundation to exam level, each with a full worked solution. Try them before revealing the solution.

foundation2 marksState whether the DELETE method is idempotent, and justify your answer.

Show worked solution →

DELETE is idempotent. Deleting a resource once removes it; sending the same DELETE request again has no further effect because the resource is already gone (the server typically returns 404 or 204 on the repeat), so the end state of the server is the same regardless of how many times the request is sent.

Marking criteria: 1 mark for correctly stating idempotent, 1 mark for a valid justification referring to the unchanged end state.

foundation3 marksA client requests a page that no longer exists on the server. State the status code the server should return, its numeric range classification, and what that range means.

Show worked solution →

The server should return 404 Not Found. This falls in the 4xx range, which classifies client errors, meaning something about the request itself (in this case, the requested resource/path) was invalid from the server's point of view, as opposed to a fault in the server.

Marking criteria: 1 mark for the correct code (404), 1 mark for the correct range (4xx), 1 mark for correctly explaining what 4xx signifies.

core4 marksThe stimulus below shows part of an HTTP response header block. Identify what each of the two headers instructs a receiving browser or cache to do. ``` HTTP/1.1 200 OK Cache-Control: no-store Set-Cookie: session=93af1c; HttpOnly ```

Show worked solution →

Cache-Control: no-store instructs the browser and any intermediate caches not to store any copy of this response at all, meaning every future request for the same resource must go back to the server rather than being served from a cache. This is typically used for sensitive or rapidly changing data.

Set-Cookie: session=93af1c; HttpOnly instructs the browser to store a cookie named session with the value 93af1c and to attach it automatically to future requests to this site; the HttpOnly flag additionally tells the browser to block client-side JavaScript from reading the cookie, reducing the impact of a cross-site scripting attack.

Marking criteria: 2 marks for correctly explaining Cache-Control: no-store, 2 marks for correctly explaining Set-Cookie including the effect of HttpOnly.

core5 marksExplain why a REST API that returns status code 200 OK for every response, embedding an 'error' field in the JSON body when something fails, is a poor design, and describe a better approach.

Show worked solution →

HTTP status codes are the machine-readable signal that clients, proxies, load balancers, monitoring tools and caches rely on to decide what happened, without needing to parse the response body. Always returning 200 tells all of these systems "success, this can be cached and treated as normal", even when the request actually failed, e.g. due to bad input or a missing resource.

This breaks automated error handling: a caching layer might store a failed response as if it were valid data, and monitoring dashboards that alert on non-2xx rates will not detect the failures at all, hiding real problems from the team.

A better approach uses the status code to carry the actual outcome: 400 for malformed client input, 401 for missing/invalid authentication, 403 for a forbidden action, 404 for a missing resource, and 500 for an unhandled server fault, while the JSON body can still carry a human-readable message for developers or end users. This lets both machines (via the status code) and humans (via the body) understand the outcome correctly.

Marking criteria: 1 mark for identifying that status codes are meant to be machine-readable/relied on by infrastructure, 2 marks for explaining a concrete consequence of always returning 200 (e.g. caching a failure, broken monitoring), 2 marks for describing the corrected design using appropriate status codes.

core4 marksExplain, in terms of the TLS handshake, why HTTPS uses BOTH asymmetric and symmetric encryption rather than just one of the two.

Show worked solution →

Asymmetric encryption (using a public/private key pair) is used at the START of the handshake because it lets the client verify the server's certificate and securely agree on a shared secret without ever having exchanged a secret key beforehand; however, asymmetric algorithms are computationally expensive and too slow to encrypt an entire browsing session.

Once the handshake establishes a shared secret, both sides switch to symmetric encryption (e.g. AES) for the bulk of the session's actual traffic, because symmetric algorithms are far faster and adequate once both parties already share the same key.

Using asymmetric encryption solves the "how do two strangers agree on a secret over an insecure channel" problem, while symmetric encryption solves the "encrypt lots of data quickly" problem; combining them gets the security benefit of the first with the performance of the second.

Marking criteria: 1 mark for identifying asymmetric encryption is used for the initial key exchange/certificate verification, 1 mark for identifying symmetric encryption is used for the bulk session data, 2 marks for explaining WHY each is chosen for its role (security of key exchange vs speed of bulk encryption).

exam7 marksA school's assignment portal currently runs over plain HTTP. Assess the security risks this creates for students submitting assignments, and justify a migration to HTTPS, including what HTTPS does and does not protect against.

Show worked solution →

This is a 7-mark ASSESS: markers want a judgement backed by specific risks and an honest account of the limits of the fix.

Risks of plain HTTP: On a shared network (school Wi-Fi, a public network at home), plain HTTP traffic is sent as cleartext. An attacker on the same network can use packet-sniffing tools to read login credentials, session cookies, and the content of submitted assignments as they cross the network (a confidentiality failure). Because there is no integrity check, the same attacker could also modify a submission or an assignment's marks in transit without detection. Without server authentication, a malicious actor could also set up a fake copy of the portal (e.g. via DNS spoofing or a rogue Wi-Fi access point) that looks identical, capturing student logins directly.
What migrating to HTTPS fixes: HTTPS (HTTP over TLS) directly addresses all three risks: confidentiality via encryption (an eavesdropper on the network sees only ciphertext), integrity via message authentication codes built into TLS (tampering is detected and the connection is dropped), and server authentication via the digital certificate (the browser verifies it is really talking to the school's real portal, not an impersonator), shown to the student as a padlock icon.
What HTTPS does NOT protect against: HTTPS secures data in transit only. It does not protect a student's password if they reuse it elsewhere and it is leaked from a different, unrelated breach; it does not stop a student sharing their own login with a friend; it does not protect data once it is stored (at rest) on the server, which needs separate measures such as database encryption and access control; and it does not stop phishing pages that trick a student into typing credentials into a convincing fake site with its own valid certificate.
Judgement: Migrating to HTTPS is a necessary and low-cost fix for the specific, serious risks of eavesdropping, tampering and impersonation on a network the school does not fully control, but it must be paired with server-side measures (password hashing, access control, staff training against phishing) because HTTPS alone does not make the whole system secure.

Marking criteria: 2 marks for correctly identifying confidentiality, integrity and authentication risks of plain HTTP with a concrete scenario, 2 marks for correctly explaining how HTTPS addresses each, 2 marks for correctly identifying at least two genuine limitations of HTTPS (in-transit only), 1 mark for an explicit, justified judgement.