Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Support custom HTTP headers on `docker pull` / `docker push` (parity with ORAS and git)

オープン
#7,238 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
docker, go
領域
cli, networking

調査の方向性

まず、docker pull コマンドと docker push コマンドのエントリポイントから daemon の registry リクエストまでを追跡し、次に ORAS と git が繰り返し指定可能なヘッダーをどのように扱っているかを比較します。完了条件は、両方のコマンドが -H/--header を複数回受け付け、それらのヘッダーを registry リクエストに渡し、flag がない場合の現在の動作を維持し、予約済みヘッダーの扱いを定義することです。

索引モデルが issue の本文から書いたものです。

説明

kind/feature status/0-triage
Description

Summary

Add a repeatable --header / -H "Key: Value" flag to docker pull and docker push that attaches user-supplied HTTP headers to the registry requests the daemon makes. This brings the docker CLI to parity with tooling that already supports it (ORAS, git).

Motivation

Today the only header a client can influence on a pull/push is the credential from docker login (Basic or Bearer). That is not enough for a growing set of real setups:

  • Parity with ORAS. oras pull, oras push, and oras cp already support --header, and it is widely used for custom registry and gateway integrations. Users who need a header today are pushed off the docker CLI onto ORAS or bespoke clients, losing docker daemon integration.
  • Custom auth proxies / gateways. Registries fronted by a proxy that expects a header other than Basic/Bearer — an API-key header, a signed token, a tenant or region selector — cannot be used with plain docker pull. docker login can only express the standard credential.
  • Header-based routing / multi-tenancy. A gateway that routes or scopes based on a custom header (e.g. X-Tenant) has no way to receive it from docker.
  • Observability in CI. Passing correlation/trace headers (X-Request-ID, traceparent) through pulls to debug slow or failing registry paths.
  • Experimenting with registry extensions. Custom registries trying out new capabilities need a header channel without asking every user to fork the CLI.

Prior art

This is well precedented:

  • ORAS --header / -H (same ecosystem, OCI registries).
  • git http.extraHeader (git -c http.extraHeader="Key: Value" clone …) — added for exactly these proxy/auth scenarios.
  • curl -H.

Proposed UX

docker pull  -H "X-Example: value" [-H "X-Other: value"] registry/name:tag
docker push  -H "X-Example: value" registry/name:tag

Repeatable; headers applied to the registry requests for that command. Reserved headers (e.g. Authorization, Host) could be rejected or gated to avoid surprising interactions with existing auth.

Alternatives considered

  • Credential helpers — only cover authentication, not arbitrary headers.
  • ORAS — works, but does not load images into the docker daemon.
  • Forking the CLI — impractical for end users.

Compatibility

Fully opt-in and backward compatible: no --header means no change

主要言語
Go
スター
6.1k
フォーク
2.2k
平均マージ
1日 10時間
マージ済み PR(30日)
47

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

docker/cli のほかの issue

docker/cli の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。