fetch-pack: accept absolute-path packfile URIs - #76
Open
friel-openai wants to merge 1 commit into
Open
Conversation
friel-openai
marked this pull request as ready for review
August 27, 2026 08:30
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
friel-openai
force-pushed
the
af/codex/packfile-uri-absolute-path
branch
2 times, most recently
from
August 27, 2026 17:13
5176602 to
b2bf236
Compare
Packfile URIs require a scheme and authority even when the pack and the repository are served by the same HTTP(S) server. Allow the server to advertise an absolute-path reference, as defined by RFC 3986, section 4.2 [1]. Resolve it using the remote's scheme and authority, following section 5.2.2 [2]. For example, /foo.pack from https://example.com/repo.git resolves to https://example.com/foo.pack. Packfile URIs do not support local paths, so there is no ambiguity with a local file named /foo.pack. Add a separate packfile-uris-absolute-path fetch capability. The client declares support only for HTTP(S) remotes whose scheme is allowed by fetch.uriprotocols. This flag does not change the server's URI selection. When uploadpack.blobPackfileUri contains an absolute-path reference, reject packfile-URI requests without the flag before starting pack-objects. Leave fetches that do not request packfile URIs unchanged. Handle only references beginning with a single slash. Redact their paths in packet traces, as we do for absolute URIs. [1] https://www.rfc-editor.org/rfc/rfc3986.html#section-4.2 [2] https://www.rfc-editor.org/rfc/rfc3986.html#section-5.2.2 Signed-off-by: Friel <friel@openai.com>
friel-openai
force-pushed
the
af/codex/packfile-uri-absolute-path
branch
from
August 27, 2026 17:25
b2bf236 to
44c64ac
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Packfile URIs require a scheme and authority even when the pack and the
repository are served by the same HTTP(S) server.
Allow the server to advertise an absolute-path reference, as defined by
RFC 3986, section 4.2. Resolve it using the remote's scheme and
authority, following section 5.2.2. For example,
/foo.packfromhttps://example.com/repo.gitresolves tohttps://example.com/foo.pack.Packfile URIs do not support local paths, so there is no ambiguity with
a local file named
/foo.pack.Add a separate
packfile-uris-absolute-pathfetch capability. The clientdeclares support only for HTTP(S) remotes whose scheme is allowed by
fetch.uriprotocols. This flag does not change the server's URI selection.When
uploadpack.blobPackfileUricontains an absolute-path reference,reject packfile-URI requests without the flag before starting
pack-objects. Leave fetches that do not request packfile URIs unchanged.Handle only references beginning with a single slash. Redact their paths
in packet traces, as we do for absolute URIs.
I wonder if we should handle relative URIs in one go here. Should this
also support
//foo.example/bar.packandbar.pack(or../bar.pack)?We could then use one capability for relative references, rather than
negotiate each form separately.
If we're doing that, should we just follow RFC 3986, including the
query-only, fragment-only, and empty forms? Or would you prefer
to keep this patch small and stick to absolute-path references for now?