Lecture 07: Requests, responses, cookies, privacy and dynamic delivery

Outcomes and readiness

You can validate request data, construct a correct response, trace cookie coordination, explain P3P historically, and analyze redirects, negotiation, and dynamic content. Readiness: distinguish request fields from response fields.

A login trace

1. Client sends credentials in a protected POST body.
2. Server verifies them and creates an opaque session identifier.
3. Response sets Set-Cookie: SID=...; Secure; HttpOnly; SameSite=Lax; Path=/.
4. The browser stores the cookie and sends Cookie: SID=... on applicable later requests.
5. The server maps the identifier to session state and rechecks authorization for each protected action.

Never store a password or sensitive profile directly in a client-readable cookie. HttpOnly limits script access; Secure limits transmission to secure schemes; SameSite influences cross-site sending. These controls complement, rather than replace, CSRF defenses and authorization.

Request and response pipeline

Parse method/target/fields -> enforce size and type limits -> authenticate -> authorize -> validate domain input -> execute use case -> select status and representation -> set security/cache fields -> log a sanitized result. Validation errors should be distinguishable from authentication failure, authorization failure, absence, conflict, and server failure.

P3P and privacy

P3P described a machine-readable XML format for website data practices. It is a historical syllabus topic, not a substitute for current consent, minimization, security, or applicable privacy law. A machine-readable policy also does not prove that behavior matches the policy.

Worked complex interaction

Client requests /old; server returns 308 with Location: /new; client follows and sends a conditional request with If-None-Match; origin returns 304; client reuses its cached body. This single user action contains redirect, cache validation, and representation reuse.

Faded example

A form sends Content-Type: application/json but the body is invalid JSON. Hint: transport succeeded; representation parsing failed. Solution: return an appropriate client-error response (commonly 400) with a safe field-level problem; do not treat it as 500.

Common mistakes

• A cookie is not the server session itself; it can carry an identifier.
• Client-side validation improves feedback but cannot protect the server.
• Dynamic content can still be cached when rules and personalization boundaries permit it.

Practical – DI322-LAB07

Use browser tools on a test page to record a redirect chain and cookie attributes. Design a two-request session trace with exact Set-Cookie and Cookie directions. Remove secret values from evidence. Then classify six outcomes into 2xx, 3xx, 4xx, or 5xx.

Independent check

Q1 Who must validate input? Server, even if the client also validates. Q2 Who sends Set-Cookie? Server response. Q3 Who sends Cookie? User agent request. Q4 Is P3P a modern compliance guarantee? No. Q5 What does 304 reuse? A stored representation. Q6 Can generated output be cached? Yes, under correct cache and privacy rules.

Homework – DI322-A07-H1

Design request/response contracts for login, course update, missing course, validation error, and concurrent-update conflict. Include method, status, safe body, cookie/cache policy, and privacy note. Rubric: semantics 4, state/security 3, privacy 2, clarity 1.

Revision

HTTP is stateless at the message level; applications coordinate state explicitly. Correct status, cache, cookie, and privacy decisions are part of application behavior.