GET /api/artifacts/{id}/content now always sets Content-Disposition: inline by default, attachment with ?download=1, with an RFC 5987 filename* for non-ASCII names (e.g. 会议纪要.docx) plus an ASCII fallback — downloads keep correct filenames on every path, not just when the front-end uses the <a download> attribute.
contentTypeOf gains an explicit office/pdf/csv/md extension table and a mime.TypeByExtension fallback before the kind-based fallbacks, so uploaded docx/xlsx/pdf artifacts stop being served as text/plain when the MIME column is empty.
Verification
go test ./... green, including new tests: disposition on both modes, the encoded Chinese filename, and the extension/mime precedence chain (artifact_download_test.go).
## What
- `GET /api/artifacts/{id}/content` now always sets `Content-Disposition`: inline by default, `attachment` with `?download=1`, with an RFC 5987 `filename*` for non-ASCII names (e.g. 会议纪要.docx) plus an ASCII fallback — downloads keep correct filenames on every path, not just when the front-end uses the `<a download>` attribute.
- `contentTypeOf` gains an explicit office/pdf/csv/md extension table and a `mime.TypeByExtension` fallback before the kind-based fallbacks, so uploaded docx/xlsx/pdf artifacts stop being served as text/plain when the MIME column is empty.
## Verification
- `go test ./...` green, including new tests: disposition on both modes, the encoded Chinese filename, and the extension/mime precedence chain (artifact_download_test.go).
- Headless: `?download=1` → `attachment; filename*=UTF-8''demo-%E6%8A%A5...`, default → `inline`.
Task card: feature/chat-order-artifact-files (Agent-System-Dev).
Why: generated deliverables (e.g. meeting-minutes docx) had no reliable
download path — the content endpoint set no Content-Disposition, so the
filename only survived via the front-end <a download> attribute, and
contentTypeOf returned text/plain for any artifact whose MIME column was
empty, mangling office/pdf uploads.
Evidence: artifactContent now always sets Content-Disposition (inline by
default, attachment with ?download=1) with an RFC 5987 filename* for
non-ASCII names plus an ASCII fallback; contentTypeOf consults an
explicit office-format extension table then mime.TypeByExtension before
the kind fallbacks. New tests cover disposition on both modes, the
encoded Chinese filename, and the extension/mime precedence chain;
go test ./... green.
Impact: front-ends can link direct download URLs and browsers receive
correct file types for docx/xlsx/pptx/pdf/csv/md regardless of the
stored MIME value.
Refs: task feature/chat-order-artifact-files.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What
GET /api/artifacts/{id}/contentnow always setsContent-Disposition: inline by default,attachmentwith?download=1, with an RFC 5987filename*for non-ASCII names (e.g. 会议纪要.docx) plus an ASCII fallback — downloads keep correct filenames on every path, not just when the front-end uses the<a download>attribute.contentTypeOfgains an explicit office/pdf/csv/md extension table and amime.TypeByExtensionfallback before the kind-based fallbacks, so uploaded docx/xlsx/pdf artifacts stop being served as text/plain when the MIME column is empty.Verification
go test ./...green, including new tests: disposition on both modes, the encoded Chinese filename, and the extension/mime precedence chain (artifact_download_test.go).?download=1→attachment; filename*=UTF-8''demo-%E6%8A%A5..., default →inline.Task card: feature/chat-order-artifact-files (Agent-System-Dev).
44b51fab14to3a973e7ea8