Tags: harryzcy/go-httpbin
Tags
fix: /response-headers does not need escaping by default (mccutchen#208) The fix in commit 0decfd1 for a potential XSS vulnerability[1] in the `/response-headers` endpoint made an unintentionally breaking change, by HTML-escaping the body of the response when no explicit `Content-Type` is specified in the incoming request. We do not need to escape by default, because we default to a safe JSON content type in that case. [1]: GHSA-528q-4pgm-wvg2
Merge commit from fork * fix: prevent reflected XSS in `/response-headers` endpoint * link to security policy from README * decompose/refactor a bit * apply same fix to /base64 endpoint * fmt * switch to allowlist of safe content types, w/ config option for backwards compat * readme styling
ci: push to ghcr.io in addition to docker hub (mccutchen#200) Motivated by Docker's much more aggressive [rate limits][1] on unauthenticated pulls of public images going into effect on April 1: [1]: https://docs.docker.com/docker-hub/usage/
feat: allow specifying content-type for `/base64` responses (mccutche… …n#198) Given that the `/base64/{data}` (and `/base64/decode/{data}`) endpoint allows decoding arbitrary data, I think it makes sense to allow the client to also specify the `Content-Type` of that data while maintaining `text/plain` as the safe default. See conversation starting here[1] for context and motivation for this change. [1] mccutchen#141 (comment)
feat: add /env endpoint to allow exposing operator-controlled info fr… …om the server (mccutchen#189) Fixes mccutchen#114
feat: add `Server-Timing` headers/trailers where relevant (mccutchen#186 ) Here we add [Server-Timing headers/trailers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server-Timing) to endpoints that let clients control response timing: - `/delay` (header) - `/drip` (header) - `/sse` (trailer)
PreviousNext