Following the CORS configuration in caddyserver/website#324 (comment) I see that my endpoint using caddy-s3-proxy doesn't defer the response headers. Could it be because this module doesn't call next.ServeHttp(w, r) in the success case? Edit: it's not, the code needs to call ResponseWriter.WriteHeaders.

This is blocking CORS requests from working, as the Access-Control-Allow-Origin header is not present on the response.

I've sanitized the following output (from httpie).

This is the non–caddy-s3-proxy endpoint.

> http -v -d 'https://api.example.com/vanilla' \
  'origin: https://origin.example.com' \
  'x-preflight: true'
GET /vanilla HTTP/1.1
Accept: */*
Accept-Encoding: identity
Connection: keep-alive
Host: api.example.com
User-Agent: HTTPie/3.2.2
origin: https://origin.example.com
x-preflight: true



HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://api.example.com
Access-Control-Expose-Headers: Content-Encoding, Content-Type, Date, Location, Server, Transfer-Encoding
Alt-Svc: h3=":443"; ma=2592000
Content-Type: <ELIDED>
Date: <ELIDED>
Server: Caddy, <ELIDED>
Transfer-Encoding: chunked

This is the caddy-s3-proxy one.

> http -v -d 'https://api.example.com/s3proxy' \
  'origin: https://origin.example.com' \
  'x-preflight: true'
GET /s3proxy HTTP/1.1
Accept: */*
Accept-Encoding: identity
Connection: keep-alive
Host: api.example.com
User-Agent: HTTPie/3.2.2
origin: https://origin.example.com
x-preflight: true



HTTP/1.1 200 OK
Alt-Svc: h3=":443"; ma=2592000
Content-Type: <ELIDED>
Date: Wed, 08 Nov 2023
Etag: "<ELIDED>"
Last-Modified: <ELIDED>
Server: Caddy
Transfer-Encoding: chunked

Note, in particular, the lack of the Access-Control-Allow-Origin header; this means that CORS requests do not work.

I've read #33 but this seems different, as the headers should be set already (due to the defer).

Does this sound like a feature that is missing? And if so, and you don't have an alternative that you recommend for CORS, would you consider this a bug?

In that case, I can dig through the code to try to fix this, but it might be an obvious solution to you — I've skimmed https://github.com/lindenlab/caddy-s3-proxy/blob/850db193cb7f48546439d236f2a6de7bd7436e2e/s3proxy.go and found the code calls return nil in ServeHttp.

Should it be calling return next.ServeHttp(w, r), as it does in the error case?