### Checklist - [x] I'm using the latest version of the extension (Run `glab --version`) - Extension version: `glab 1.115.0 (c3612c8)` - [x] Operating system and version: Ubuntu 20.04.6 LTS, Linux 5.15.0-190-generic x86_64 - [x] Gitlab.com or self-managed instance? _both_ — the reproduction below is against gitlab.com - [x] GitLab version (if self-managed) — n/a, reproduced on gitlab.com - [x] I have performed `glab auth status` to check for authentication issues — no auth issues, and note that the reproduction below needs **no** credentials at all - [x] Run the command in debug mode — `GLAB_DEBUG_HTTP=1` output included below ### Summary In `--input` mode, `glab api` sends the request body with **no `Content-Type` header**. GitLab's API rejects that with `HTTP 415 — The provided content-type '' is not supported.` The effect is that no `--input` request can succeed without a manually added header — including the example that `glab api --help` itself prints. ### Environment - OS: Linux 5.15.0-190-generic x86_64 (Ubuntu 20.04.6 LTS) - SHELL: /bin/bash - TERM: xterm-256color - GLAB: glab 1.115.0 (c3612c8) Other: installed from the `glab` snap (`latest/stable`, rev 6569). Nothing in the reproduction looks install-specific, but I have only tested the snap build. ### Steps to reproduce `POST /markdown` is convenient here because the 415 is returned **ahead of authentication**, so this reproduces with no token and modifies nothing: ```console $ printf '{"text":"hello"}' | glab api --hostname gitlab.com -X POST --input - markdown {"error":"The provided content-type '' is not supported."} glab: HTTP 415 ``` Adding the header alone gets past it — the 401 below is only because the command is unauthenticated, i.e. the request is now being routed and authorized rather than rejected up front: ```console $ printf '{"text":"hello"}' | glab api --hostname gitlab.com -X POST --input - \ -H 'Content-Type: application/json' markdown {"message":"401 Unauthorized"} glab: 401 Unauthorized (HTTP 401) ``` **The example printed by `glab api --help` fails the same way.** Quoting it verbatim from `internal/commands/api/api.go:159`: ```shell echo '{"allowed_to_push":[{"user_id":1}]}' | GLAB_DEBUG_HTTP=1 glab api -X PATCH "projects/:fullpath/protected_branches/main" --input - ``` Run against a project path that does not exist, so that nothing can be modified: ```console $ echo '{"allowed_to_push":[{"user_id":1}]}' | glab api --hostname gitlab.com \ -X PATCH "projects/nonexistent-ns%2Fnonexistent-proj/protected_branches/main" --input - {"error":"The provided content-type '' is not supported."} glab: HTTP 415 ``` Authenticated, against a project that does exist, the result is identical — the 415 comes from content-type negotiation, which happens before routing and authorization, so neither a valid token nor a valid resource changes the outcome. ### What is the current _bug_ behavior? Every `--input` request is rejected with HTTP 415 unless the caller happens to know to add `-H "Content-Type: application/json"` themselves. The documented example cannot work as printed. ### What is the expected _correct_ behavior? `--input` should default to `Content-Type: application/json`, while still letting an explicit `-H` override it — which is what `--form` already does for its own content type. If instead the raw-body mode is deliberately content-type-agnostic, then the `--help` example should show the required `-H`, and the flag's description should say the header is the caller's responsibility. ### Relevant logs and/or screenshots `GLAB_DEBUG_HTTP=1`, request headers only, token redacted: ``` PUT /api/v4/... HTTP/1.1 Host: <redacted> Accept: application/json User-Agent: glab/1.115.0 (no Content-Type header present) < HTTP/1.1 415 Unsupported Media Type {"error":"The provided content-type '' is not supported."} ``` ### Possible fixes The three body modes are inconsistent, and `--input` is the odd one out: - `--form` prepends its content type explicitly — `internal/commands/api/api.go:329-331`: `requestHeaders = append([]string{fmt.Sprintf("Content-Type: %s", contentType)}, requestHeaders...)` - `--field` / `--raw-field` bodies are sent as JSON and work with no header (`-F 'text=@-'` against the same endpoint reaches authorization rather than returning 415) - the `--input` branch — `internal/commands/api/api.go:311-321` — sets `requestBody = file` and adds no header at all So the minimal fix looks symmetric with `--form`: in the `o.requestInputFile != ""` branch, prepend `Content-Type: application/json` unless the caller already supplied a `Content-Type` in `-H`. ### Prior art — why this is not a duplicate #8316 recorded the same 415 (“`glab api --input file.json` — `--input` doesn't set `Content-Type` header”) and fixed it by documenting the workaround in the bundled `SKILL.md`. It did not change the behavior, the flag description, or the `--help` example, so `glab api --help` still ships an example that returns 415. This issue is for that remaining behavior/documentation gap. ### Workaround, for anyone who lands here Add the header explicitly: ```shell printf '%s' "$json" | glab api -X PUT --input - -H 'Content-Type: application/json' <endpoint> ``` Or avoid `--input` altogether and let `glab` build the body, which needs no header: ```shell printf '%s' "$value" | glab api -X PUT -F 'field=@-' <endpoint> ``` The `@-` form reads the value from stdin as a string, JSON-escapes it, and sets the content type. Two things worth knowing about it: `-f` / `--raw-field` does **not** expand `@-` (it sends the two literal characters `@-`), and unlike a bare inline `-F` value the `@` form is not subject to `--field`'s type coercion or `:placeholder` substitution.