📌 Description
src/middleware/contentType.ts enforces Content-Type: application/json on write routes but there are no tests confirming that routes correctly return 406 Not Acceptable when a client sends Accept: application/xml or another non-JSON type. The Express default behavior is to return JSON regardless of the Accept header, which is technically incorrect. Tests should confirm the current behavior and, if 406 is not returned, open a ticket or add content negotiation middleware to enforce it on read routes.
💡 Why it matters: Clients relying on Accept header negotiation will silently receive JSON when they expect XML or another format, violating HTTP content negotiation contracts.
🧩 Requirements and context
- Test
GET /api/streams with Accept: application/xml — document whether it returns 200 (JSON) or 406
- Test
GET /api/streams with Accept: application/json — assert 200
- Test
GET /api/streams with Accept: */* — assert 200
- If
406 is not currently returned for application/xml, add a middleware that enforces it
- Update
tests/routes/streams.test.ts with the content-negotiation assertions
Non-functional requirements
- Must be secure, tested, and documented.
- Should be efficient and easy to review.
🛠️ Suggested execution
1. Fork the repo and create a branch
git checkout -b feat/content-negotiation-406
2. Implement changes
- Write/modify the relevant source:
src/middleware/contentType.ts, src/routes/index.ts (if middleware needed)
- Write comprehensive tests:
tests/middleware/contentNegotiation.test.ts
- Add documentation: TSDoc on the content negotiation middleware
- Include TSDoc on the
Accept header validation logic
- Validate security assumptions:
406 response must not expose server internals in the body
3. Test and commit
npm test -- --testPathPattern=contentNegotiation
- Cover edge cases:
Accept: application/json;q=0.9, application/xml;q=1.0 (XML preferred), Accept: empty header
- Include test output and security notes in the PR description.
Example commit message
feat(content-type): add 406 Not Acceptable for non-JSON Accept headers on GET routes
✅ Acceptance criteria
🔒 Security notes
The 406 response body must use the standard error envelope and must not include the raw Accept header value to prevent header-injection reflection.
📋 Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
📌 Description
src/middleware/contentType.tsenforcesContent-Type: application/jsonon write routes but there are no tests confirming that routes correctly return406 Not Acceptablewhen a client sendsAccept: application/xmlor another non-JSON type. The Express default behavior is to return JSON regardless of theAcceptheader, which is technically incorrect. Tests should confirm the current behavior and, if406is not returned, open a ticket or add content negotiation middleware to enforce it on read routes.🧩 Requirements and context
GET /api/streamswithAccept: application/xml— document whether it returns200(JSON) or406GET /api/streamswithAccept: application/json— assert200GET /api/streamswithAccept: */*— assert200406is not currently returned forapplication/xml, add a middleware that enforces ittests/routes/streams.test.tswith the content-negotiation assertionsNon-functional requirements
🛠️ Suggested execution
1. Fork the repo and create a branch
2. Implement changes
src/middleware/contentType.ts,src/routes/index.ts(if middleware needed)tests/middleware/contentNegotiation.test.tsAcceptheader validation logic406response must not expose server internals in the body3. Test and commit
npm test -- --testPathPattern=contentNegotiationAccept: application/json;q=0.9, application/xml;q=1.0(XML preferred),Accept:empty headerExample commit message
✅ Acceptance criteria
GET /api/streamswithAccept: application/xmlreturns406with JSON error bodyGET /api/streamswithAccept: application/jsonreturns200GET /api/streamswithAccept: */*returns200🔒 Security notes
The
406response body must use the standard error envelope and must not include the rawAcceptheader value to prevent header-injection reflection.📋 Guidelines