HTTP

Own permit · PD17

1. Compose. The browser asks PermitDesk to read PD17 with GET /permits/PD17. Resident R17 is already signed in; the server’s records associate this permit with R17. This synthetic HTTPS exchange assumes working transport and a valid server-managed R17 session. GET requests a representation, not a permit update. Headers carry the session context, but no session secret is displayed. The labels describe HTTP meaning, not a literal wire capture.
2. Request. The browser sends the request to PermitDesk. Service receipt appears after arrival. Neither an HTTP response nor permit content has reached the browser yet. The request identifies its method and target resource and includes relevant headers. This example sends no request body. The original permits stay stored at the application; the client’s choice does not change authoritative ownership.
3. Handle. PermitDesk checks R17’s valid session and its own permit-ownership records. PD17 belongs to R17, so its own-permit policy allows this read and prepares a 200 OK representation. The application enforces permission before releasing content. HTTPS and valid syntax do not supply that decision. A status prepared at the server has not reached the browser. The valid R17 session maps to PD17’s owner, so this read is allowed; that permission does not approve the permit or complete a business workflow.
4. Response. The 200 response travels back to the browser. After arrival, it shows 200 OK and the synthetic PD17 representation. The original permit remains at the application. The authored response has status 200, Content-Type application/json, and the complete short body {"permit":"PD17"}. Its receipt means this representation arrived, not that a permit was approved or a business workflow completed. HTTP responses can use other statuses and bodies.

Other account · PD29

1. Compose. The browser asks PermitDesk to read PD29 with GET /permits/PD29. Resident R17 is already signed in; the server’s records associate this permit with R29. This synthetic HTTPS exchange assumes working transport and a valid server-managed R17 session. GET requests a representation, not a permit update. Headers carry the session context, but no session secret is displayed. The labels describe HTTP meaning, not a literal wire capture.
2. Request. The browser sends the request to PermitDesk. Service receipt appears after arrival. Neither an HTTP response nor permit content has reached the browser yet. The request identifies its method and target resource and includes relevant headers. This example sends no request body. The original permits stay stored at the application; the client’s choice does not change authoritative ownership.
3. Handle. PermitDesk checks R17’s valid session and its own permit-ownership records. PD29 belongs to R29, so its own-permit policy refuses this read and prepares 403 Forbidden without permit content. The application enforces permission before releasing content. HTTPS and valid syntax do not supply that decision. A status prepared at the server has not reached the browser. The refusal preserves the working session and transport; 403 is the chosen policy response here, not a sign-in failure.
4. Response. The 403 response travels back to the browser. After arrival, it shows 403 Forbidden and no permit data. R17 remains signed in; the other account’s permit is retained at the application. This authored 403 response has headers and no response content. HTTP permits refusal content, but none is included here. The code means this request was refused; it does not invalidate R17’s session or prove a transport failure.

This is one GET exchange with two authored outcomes. It does not establish every HTTP encoding, status, transport version, or business result. Application permission is separate from HTTPS protection.

Flow references: RFC 9110 - requests, GET, 200, and 403 · OWASP - server-side permission on every request