优化代码结构，支持h2 #39

2025-07-27T11:54:19+08:00

sky22333 commented

2025-07-27 11:54:19 +08:00

(Migrated from github.com)

Summary by CodeRabbit

New Features
- Added support for HTTP/2 Cleartext (H2C) multiplexing, configurable via settings and environment variables.
- Introduced a GitHub proxy endpoint for handling GitHub-related requests with smart script processing and redirect handling.
Improvements
- Increased default rate limit window and request limit for enhanced throughput.
- Refined configuration options and documentation for easier setup and management.
- Docker proxy and image tar streaming features are now modular and more maintainable.
Refactor
- Major codebase reorganization: proxy logic, handlers, configuration, and utilities are now separated into dedicated packages for improved clarity and maintainability.
- Exported key functions and variables for better modularity and extensibility.
Documentation
- Updated README and configuration examples to reflect new options and improved clarity.
Style
- Code comments streamlined and formatting improved for consistency.

No changes to core user-facing workflows except as noted above.

## Summary by CodeRabbit * **New Features** * Added support for HTTP/2 Cleartext (H2C) multiplexing, configurable via settings and environment variables. * Introduced a GitHub proxy endpoint for handling GitHub-related requests with smart script processing and redirect handling. * **Improvements** * Increased default rate limit window and request limit for enhanced throughput. * Refined configuration options and documentation for easier setup and management. * Docker proxy and image tar streaming features are now modular and more maintainable. * **Refactor** * Major codebase reorganization: proxy logic, handlers, configuration, and utilities are now separated into dedicated packages for improved clarity and maintainability. * Exported key functions and variables for better modularity and extensibility. * **Documentation** * Updated README and configuration examples to reflect new options and improved clarity. * **Style** * Code comments streamlined and formatting improved for consistency. No changes to core user-facing workflows except as noted above.

coderabbitai[bot] commented

2025-07-27 11:54:33 +08:00

(Migrated from github.com)

Walkthrough

This update refactors and modularizes the codebase, moving logic from the main entry point into dedicated packages for configuration, utilities, and handlers. It introduces a new GitHub proxy handler, adds HTTP/2 Cleartext (H2C) support, revises configuration defaults, and exports previously internal functions and variables for broader package use.

Changes

File(s) / Path(s)	Change Summary
README.md, src/config.toml	Updated documentation and config examples: added `enableH2C` option, increased rate limit period, renamed `[proxy]` to `[access]`, removed example proxy URLs.
docker-compose.yml	Changed indentation of `hubproxy` service for consistency; no functional changes.
src/go.mod	Promoted `golang.org/x/net` to direct dependency.
src/config/config.go	Refactored to `config` package, added `EnableH2C` field, increased default rate limit, added env override for H2C, removed comments.
src/handlers/docker.go, src/handlers/imagetar.go, src/handlers/search.go	Refactored to use `handlers` package, centralized config and utilities, renamed and exported several functions, removed redundant comments.
src/handlers/github.go	Added: new GitHub proxy handler with URL validation, access control, redirect handling, and smart shell script processing.
src/main.go	Major refactor: moved proxy logic to handlers, modularized initialization, added H2C support, improved health endpoint, cleaned up imports and comments.
src/utils/access_control.go, src/utils/cache.go, src/utils/http_client.go, src/utils/proxy_shell.go, src/utils/ratelimiter.go	Refactored to `utils` package, updated imports, exported previously internal functions/variables, introduced shared whitelist limiter in rate limiter, removed or simplified comments.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant GinRouter
    participant GitHubProxyHandler
    participant AccessController
    participant HTTPClient

    Client->>GinRouter: HTTP request (unmatched route)
    GinRouter->>GitHubProxyHandler: Call handler
    GitHubProxyHandler->>AccessController: Check GitHub URL access
    AccessController-->>GitHubProxyHandler: Access allowed/denied
    GitHubProxyHandler->>HTTPClient: Proxy request (with redirects)
    HTTPClient-->>GitHubProxyHandler: Response (possibly redirect)
    GitHubProxyHandler->>GinRouter: Stream response to client
    GinRouter-->>Client: Return proxied content or error

sequenceDiagram
    participant Main
    participant Config
    participant Utils
    participant Handlers
    participant GinRouter

    Main->>Config: LoadConfig()
    Main->>Utils: InitHTTPClients()
    Main->>Utils: InitGlobalLimiter()
    Main->>Handlers: InitDockerProxy()
    Main->>Handlers: InitImageStreamer()
    Main->>Handlers: InitDebouncer()
    Main->>GinRouter: Register routes (search, docker, image, health, NoRoute)
    Main->>GinRouter: Start HTTP server (with optional H2C)

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~40 minutes

Poem

Oh, what a hop through the code today!
We’ve split up the logic, sent main on its way.
Now handlers and utils, so neat and so spry,
Serve GitHub and Docker as requests hop by.
With H2C speed and a proxy so bright,
This rabbit’s code garden grows just right!
🐇✨

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

✨ Finishing Touches

📝 Generate Docstrings

🧪 Generate unit tests

Create PR with unit tests
Post copyable unit tests in a comment
Commit unit tests in branch dev

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Explain this complex logic.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai explain this code block.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and explain its main purpose.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
- @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai generate docstrings to generate docstrings for this PR.
@coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
@coderabbitai generate unit tests to generate unit tests for this PR.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
Please see the configuration documentation for more information.
If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

## Walkthrough This update refactors and modularizes the codebase, moving logic from the main entry point into dedicated packages for configuration, utilities, and handlers. It introduces a new GitHub proxy handler, adds HTTP/2 Cleartext (H2C) support, revises configuration defaults, and exports previously internal functions and variables for broader package use. ## Changes | File(s) / Path(s) | Change Summary | |--------------------------------------------------------|---------------| | README.md, src/config.toml | Updated documentation and config examples: added `enableH2C` option, increased rate limit period, renamed `[proxy]` to `[access]`, removed example proxy URLs. | | docker-compose.yml | Changed indentation of `hubproxy` service for consistency; no functional changes. | | src/go.mod | Promoted `golang.org/x/net` to direct dependency. | | src/config/config.go | Refactored to `config` package, added `EnableH2C` field, increased default rate limit, added env override for H2C, removed comments. | | src/handlers/docker.go, src/handlers/imagetar.go, src/handlers/search.go | Refactored to use `handlers` package, centralized config and utilities, renamed and exported several functions, removed redundant comments. | | src/handlers/github.go | Added: new GitHub proxy handler with URL validation, access control, redirect handling, and smart shell script processing. | | src/main.go | Major refactor: moved proxy logic to handlers, modularized initialization, added H2C support, improved health endpoint, cleaned up imports and comments. | | src/utils/access_control.go, src/utils/cache.go, src/utils/http_client.go, src/utils/proxy_shell.go, src/utils/ratelimiter.go | Refactored to `utils` package, updated imports, exported previously internal functions/variables, introduced shared whitelist limiter in rate limiter, removed or simplified comments. | ## Sequence Diagram(s) ```mermaid sequenceDiagram participant Client participant GinRouter participant GitHubProxyHandler participant AccessController participant HTTPClient Client->>GinRouter: HTTP request (unmatched route) GinRouter->>GitHubProxyHandler: Call handler GitHubProxyHandler->>AccessController: Check GitHub URL access AccessController-->>GitHubProxyHandler: Access allowed/denied GitHubProxyHandler->>HTTPClient: Proxy request (with redirects) HTTPClient-->>GitHubProxyHandler: Response (possibly redirect) GitHubProxyHandler->>GinRouter: Stream response to client GinRouter-->>Client: Return proxied content or error ``` ```mermaid sequenceDiagram participant Main participant Config participant Utils participant Handlers participant GinRouter Main->>Config: LoadConfig() Main->>Utils: InitHTTPClients() Main->>Utils: InitGlobalLimiter() Main->>Handlers: InitDockerProxy() Main->>Handlers: InitImageStreamer() Main->>Handlers: InitDebouncer() Main->>GinRouter: Register routes (search, docker, image, health, NoRoute) Main->>GinRouter: Start HTTP server (with optional H2C) ``` ## Estimated code review effort 🎯 4 (Complex) | ⏱️ ~40 minutes ## Poem > Oh, what a hop through the code today! > We’ve split up the logic, sent main on its way. > Now handlers and utils, so neat and so spry, > Serve GitHub and Docker as requests hop by. > With H2C speed and a proxy so bright, > This rabbit’s code garden grows just right! > 🐇✨   > [!NOTE] > <details open="true"> > <summary>⚡️ Unit Test Generation is now available in beta!</summary> > > Learn more [here](https://docs.coderabbit.ai/finishing-touches/unit-test-generation), or try it out under "Finishing Touches" below. > > </details>      <details> <summary>✨ Finishing Touches</summary> - [ ]  📝 Generate Docstrings <details> <summary>🧪 Generate unit tests</summary> - [ ]  Create PR with unit tests - [ ]  Post copyable unit tests in a comment - [ ]  Commit unit tests in branch `dev` </details> </details>   --- Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. <details> <summary>❤️ Share</summary> - [X](https://twitter.com/intent/tweet?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A&url=https%3A//coderabbit.ai) - [Mastodon](https://mastodon.social/share?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A%20https%3A%2F%2Fcoderabbit.ai) - [Reddit](https://www.reddit.com/submit?title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&text=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code.%20Check%20it%20out%3A%20https%3A//coderabbit.ai) - [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoderabbit.ai&mini=true&title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&summary=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code) </details> <details> <summary>🪧 Tips</summary> ### Chat There are 3 ways to chat with [CodeRabbit](https://coderabbit.ai?utm_source=oss&utm_medium=github&utm_campaign=sky22333/hubproxy&utm_content=39): - Review comments: Directly reply to a review comment made by CodeRabbit. Example: - `I pushed a fix in commit <commit_id>, please review it.` - `Explain this complex logic.` - `Open a follow-up GitHub issue for this discussion.` - Files and specific lines of code (under the "Files changed" tab): Tag `@coderabbitai` in a new review comment at the desired location with your query. Examples: - `@coderabbitai explain this code block.` - `@coderabbitai modularize this function.` - PR comments: Tag `@coderabbitai` in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples: - `@coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.` - `@coderabbitai read src/utils.ts and explain its main purpose.` - `@coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.` - `@coderabbitai help me debug CodeRabbit configuration file.` ### Support Need help? Create a ticket on our [support page](https://www.coderabbit.ai/contact-us/support) for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. ### CodeRabbit Commands (Invoked using PR comments) - `@coderabbitai pause` to pause the reviews on a PR. - `@coderabbitai resume` to resume the paused reviews. - `@coderabbitai review` to trigger an incremental review. This is useful when automatic reviews are disabled for the repository. - `@coderabbitai full review` to do a full review from scratch and review all the files again. - `@coderabbitai summary` to regenerate the summary of the PR. - `@coderabbitai generate docstrings` to [generate docstrings](https://docs.coderabbit.ai/finishing-touches/docstrings) for this PR. - `@coderabbitai generate sequence diagram` to generate a sequence diagram of the changes in this PR. - `@coderabbitai generate unit tests` to generate unit tests for this PR. - `@coderabbitai resolve` resolve all the CodeRabbit review comments. - `@coderabbitai configuration` to show the current CodeRabbit configuration for the repository. - `@coderabbitai help` to get help. ### Other keywords and placeholders - Add `@coderabbitai ignore` anywhere in the PR description to prevent this PR from being reviewed. - Add `@coderabbitai summary` to generate the high-level summary at a specific location in the PR description. - Add `@coderabbitai` anywhere in the PR title to generate the title automatically. ### CodeRabbit Configuration File (`.coderabbit.yaml`) - You can programmatically configure CodeRabbit by adding a `.coderabbit.yaml` file to the root of your repository. - Please see the [configuration documentation](https://docs.coderabbit.ai/guides/configure-coderabbit) for more information. - If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: `# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json` ### Documentation and Community - Visit our [Documentation](https://docs.coderabbit.ai) for detailed information on how to use CodeRabbit. - Join our [Discord Community](http://discord.gg/coderabbit) to get help, request features, and share feedback. - Follow us on [X/Twitter](https://twitter.com/coderabbitai) for updates and announcements. </details>

coderabbitai[bot] (Migrated from github.com) reviewed 2025-07-27 12:00:56 +08:00

coderabbitai[bot] (Migrated from github.com) left a comment

Actionable comments posted: 2

🧹 Nitpick comments (7)

docker-compose.yml (1)
1-8: Add trailing newline to satisfy YAML linters and POSIX tools

yamllint flagged the missing newline at EOF. Some tools (e.g. POSIX sed, cat) expect the last line to be newline-terminated; adding it avoids subtle processing glitches.
       - ./src/config.toml:/root/config.toml
+
src/go.mod (1)
5-11: Run go mod tidy after promoting golang.org/x/net to direct

Promoting the dependency is sensible given the new H2C handler. Running
go mod tidy
will prune any now-unused transitive deps and lock in the minimal go.sum.
README.md (2)

112-114: Highlight security caveat for enableH2C

H2C (HTTP/2 cleartext) omits TLS. Recommend adding a doc note that it should only be enabled behind a trusted TLS-terminating reverse proxy to avoid downgrading security.

119-120: Rate-limit window change: update examples & alerts

The period changed to 3 h; ensure any alerting/monitoring or README examples (e.g. “每小时请求数”) are likewise updated so users don’t mis-interpret the limits.

src/config.toml (2)

7-8: enableH2C defaults to false — ensure reverse proxy handles HTTP/2 if later enabled

Enabling H2C exposes the service over cleartext HTTP/2; verify your ingress (Caddy / Nginx) supports h2c upgrade, otherwise clients will fall back to HTTP/1.1 and lose multiplexing benefits.

14-14: Keep comment in sync: limit is now 3 h, not “每小时”

The Chinese comment still says “每小时允许的请求数”; with a 3-hour window that’s misleading. Consider updating to “每 3 小时”.
src/handlers/search.go (1)
152-161: Consider goroutine lifecycle management.

The cleanup goroutine started in init() runs indefinitely without a shutdown mechanism. Consider:

Using a context for graceful shutdown

Providing a way to stop the cleanup routine when the application shuts down
-func init() {
-	go func() {
-		ticker := time.NewTicker(5 * time.Minute)
-		defer ticker.Stop()
-
-		for range ticker.C {
-			searchCache.Cleanup()
-		}
-	}()
-}
+var cleanupDone chan struct{}
+
+func init() {
+	cleanupDone = make(chan struct{})
+	go func() {
+		ticker := time.NewTicker(5 * time.Minute)
+		defer ticker.Stop()
+
+		for {
+			select {
+			case <-ticker.C:
+				searchCache.Cleanup()
+			case <-cleanupDone:
+				return
+			}
+		}
+	}()
+}
+
+// StopCacheCleanup stops the cache cleanup goroutine
+func StopCacheCleanup() {
+	if cleanupDone != nil {
+		close(cleanupDone)
+	}
+}

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between badafd2899 and 07a926902a.

📒 Files selected for processing (15)

README.md (3 hunks)
docker-compose.yml (1 hunks)
src/config.toml (1 hunks)
src/config/config.go (6 hunks)
src/go.mod (1 hunks)
src/handlers/docker.go (17 hunks)
src/handlers/github.go (1 hunks)
src/handlers/imagetar.go (11 hunks)
src/handlers/search.go (1 hunks)
src/main.go (5 hunks)
src/utils/access_control.go (4 hunks)
src/utils/cache.go (6 hunks)
src/utils/http_client.go (2 hunks)
src/utils/proxy_shell.go (1 hunks)
src/utils/ratelimiter.go (7 hunks)

🧰 Additional context used

🧬 Code Graph Analysis (5)

src/utils/http_client.go (2)

src/config/config.go (1)

GetConfig (148-184)

src/http_client.go (3)

initHTTPClients (18-58)

GetGlobalHTTPClient (61-63)

GetSearchHTTPClient (66-68)

src/handlers/imagetar.go (3)

src/config/config.go (1)

GetConfig (148-184)

src/utils/http_client.go (1)

GetGlobalHTTPClient (60-62)

src/imagetar.go (9)

initDebouncer (131-136)

handleSimpleBatchDownload (657-724)

initImageTarRoutes (595-602)

handleDirectImageDownload (605-654)

StreamMultipleImages (786-884)

cleanup (81-87)

NewDownloadDebouncer (43-49)

processImageForBatch (460-482)

StreamImageToGin (223-237)

src/utils/access_control.go (1)

src/config/config.go (1)

GetConfig (148-184)

src/utils/cache.go (1)

src/config/config.go (1)

GetConfig (148-184)

src/handlers/docker.go (5)

src/config/config.go (2)

GetConfig (148-184)

RegistryMapping (15-20)

src/utils/http_client.go (1)

GetGlobalHTTPClient (60-62)

src/utils/access_control.go (1)

GlobalAccessController (32-32)

src/utils/cache.go (9)

IsCacheEnabled (132-135)

BuildManifestCacheKey (70-73)

GlobalCache (28-28)

WriteCachedResponse (119-129)

GetManifestTTL (75-94)

IsTokenCacheEnabled (138-140)

BuildTokenCacheKey (66-68)

WriteTokenResponse (114-117)

ExtractTTLFromResponse (97-112)

src/docker.go (9)

proxyDockerAuthOriginal (388-466)

ProxyDockerRegistryGin (85-100)

handleRegistryRequest (103-150)

rewriteAuthHeader (469-477)

handleUpstreamManifestRequest (520-593)

handleMultiRegistryRequest (480-517)

handleManifestRequest (180-256)

ProxyDockerAuthGin (331-338)

proxyDockerAuthWithCache (341-370)

🪛 YAMLlint (1.37.1)

docker-compose.yml

[error] 8-8: no new line character at the end of file

(new-line-at-end-of-file)

🔇 Additional comments (25)

docker-compose.yml (1)

1-8: Confirm indentation convention is now 2 spaces project-wide

You switched this file from 4- to 2-space indents. If other YAML manifests in the repo still use 4 spaces, consider normalising to one style to avoid churn in future diffs.

src/utils/proxy_shell.go (1)

1-1: Package rename looks correct; verify all import paths compile

Moving the file into package utils is consistent with the refactor, but make sure all call-sites have updated imports (hubproxy/utils or equivalent).
A quick go vet ./... + go test ./... after go mod tidy will catch any dangling references.

README.md (2)

40-41: Verify updated install script URL exists

install-service.sh → install.sh change is fine, but please confirm the new script is pushed to main and is executable; broken quick-start links frustrate first-time users.

137-149: Section renamed to [access]; double-check code uses new key

Config struct tags and env-var overrides must match this rename. A mismatch silently falls back to defaults.

src/utils/access_control.go (3)

1-1: LGTM! Package restructuring looks good.

The package name change to utils and the addition of the config import are consistent with the modularization efforts in this PR.

Also applies to: 6-7

31-31: Good improvement: English documentation.

Translating the comment to English improves code accessibility for international contributors.

84-84: Correct usage of centralized config.

The updates to use config.GetConfig() properly leverage the centralized configuration package.

Also applies to: 109-109

src/utils/http_client.go (2)

1-1: Package restructuring is consistent.

The package name change and config import align with the overall modularization approach.

Also applies to: 8-9

17-19: Properly exported HTTP client functions.

The exported function names follow Go conventions and provide appropriate access to the HTTP clients from other packages.

Also applies to: 59-60, 64-65

src/config/config.go (4)

1-1: Appropriate package name for configuration module.

The config package name correctly reflects the module's purpose.

28-28: Well-implemented H2C support.

The HTTP/2 Cleartext support is properly implemented with:

Opt-in by default (false)

Configuration via TOML and environment variable

Proper error handling for boolean parsing

This aligns perfectly with the PR objective.

Also applies to: 76-77, 81-81, 225-229

87-88: Verify the rate limit configuration changes.

The request limit increased from 20 to 200 (10x increase). The AI summary mentions the period was extended to 3 hours, but the code shows PeriodHours: 1.0. Please confirm:

Is the 10x rate limit increase intentional and based on actual usage patterns?

Should PeriodHours be 3.0 instead of 1.0?

Likely an incorrect or invalid review comment.

16-20: Well-structured configuration types.

The struct definitions with TOML tags are properly implemented for configuration serialization.

Also applies to: 25-29

src/handlers/search.go (2)

1-17: Well-structured handler package.

The package organization and imports are appropriate for a search handler module.

279-279: Correct usage of search HTTP client.

Properly uses the search-specific HTTP client from utils package with appropriate timeouts for API calls.

Also applies to: 432-432

src/handlers/github.go (2)

17-30: Comprehensive URL pattern matching.

The regex patterns cover all major GitHub-related services and are pre-compiled for performance.

93-98: Good redirect loop protection.

The implementation properly limits redirects to 20 and returns an appropriate HTTP 508 status code.

src/utils/ratelimiter.go (3)

1-1: LGTM! Package refactoring aligns with modularization.

The package rename from main to utils and import update to use hubproxy/config are consistent with the broader refactoring effort.

Also applies to: 12-12

28-28: Good optimization for whitelist IP handling.

The addition of a shared whitelistLimiter with infinite rate is an efficient approach that:

Reduces memory usage by avoiding individual limiter creation for each whitelist IP

Clearly indicates that whitelist IPs have no rate limiting

Maintains burst size configuration for consistency

Also applies to: 85-85, 174-175

45-45: Minor: String concatenation style change.

The change from compound assignment to explicit concatenation is functionally equivalent. Both approaches work correctly in this context.

Also applies to: 60-60

src/handlers/imagetar.go (1)

1-1: LGTM! Clean modularization of image streaming functionality.

The refactoring successfully:

Moves functionality to the handlers package

Exports initialization functions for external use

Centralizes configuration and HTTP client access through config and utils packages

Maintains all core functionality while improving modularity

Also applies to: 26-27, 123-127, 141-157, 563-566, 576-584

src/utils/cache.go (1)

1-1: LGTM! Well-structured cache utilities export.

The refactoring properly:

Exports cache types and functions for cross-package use

Creates a global GlobalCache instance safely initialized

Centralizes configuration access through the config package

Maintains thread-safe operations with the existing sync.Map

Also applies to: 12-12, 15-28, 61-140

src/handlers/docker.go (1)

1-1: LGTM! Comprehensive refactoring of Docker proxy handlers.

The refactoring successfully:

Migrates all configuration access to use config.GetConfig()

Updates all cache operations to use utils.GlobalCache and related functions

Properly uses utils.GlobalAccessController for access control

Updates function signatures to use the exported config.RegistryMapping type

Maintains all proxy functionality while improving modularity

Also applies to: 15-16, 32-58, 62-80, 122-122, 170-177, 219-223, 299-330, 440-440, 461-467, 513-517

src/main.go (2)

12-13: H2C support implementation looks good.

The HTTP/2 Cleartext support is properly implemented with:

Conditional enablement based on configuration

Reasonable stream limits and buffer sizes

Appropriate timeout configurations

Clear logging of H2C status

Also applies to: 124-150

44-116: Excellent modularization of main.go!

The refactoring successfully:

Delegates all initialization to dedicated packages

Removes embedded proxy logic in favor of handler packages

Simplifies the main function to focus on server setup

Improves the health check endpoint with cleaner implementation

Also applies to: 173-187

**Actionable comments posted: 2** <details> <summary>🧹 Nitpick comments (7)</summary><blockquote> <details> <summary>docker-compose.yml (1)</summary><blockquote> `1-8`: **Add trailing newline to satisfy YAML linters and POSIX tools** `yamllint` flagged the missing newline at EOF. Some tools (e.g. POSIX `sed`, `cat`) expect the last line to be newline-terminated; adding it avoids subtle processing glitches. ```diff - ./src/config.toml:/root/config.toml + ``` </blockquote></details> <details> <summary>src/go.mod (1)</summary><blockquote> `5-11`: **Run `go mod tidy` after promoting `golang.org/x/net` to direct** Promoting the dependency is sensible given the new H2C handler. Running ```bash go mod tidy ``` will prune any now-unused transitive deps and lock in the minimal `go.sum`. </blockquote></details> <details> <summary>README.md (2)</summary><blockquote> `112-114`: **Highlight security caveat for `enableH2C`** H2C (HTTP/2 cleartext) omits TLS. Recommend adding a doc note that it should only be enabled behind a trusted TLS-terminating reverse proxy to avoid downgrading security. --- `119-120`: **Rate-limit window change: update examples & alerts** The period changed to 3 h; ensure any alerting/monitoring or README examples (e.g. “每小时请求数”) are likewise updated so users don’t mis-interpret the limits. </blockquote></details> <details> <summary>src/config.toml (2)</summary><blockquote> `7-8`: **`enableH2C` defaults to false — ensure reverse proxy handles HTTP/2 if later enabled** Enabling H2C exposes the service over cleartext HTTP/2; verify your ingress (Caddy / Nginx) supports `h2c` upgrade, otherwise clients will fall back to HTTP/1.1 and lose multiplexing benefits. --- `14-14`: **Keep comment in sync: limit is now 3 h, not “每小时”** The Chinese comment still says “每小时允许的请求数”; with a 3-hour window that’s misleading. Consider updating to “每 3 小时”. </blockquote></details> <details> <summary>src/handlers/search.go (1)</summary><blockquote> `152-161`: **Consider goroutine lifecycle management.** The cleanup goroutine started in `init()` runs indefinitely without a shutdown mechanism. Consider: 1. Using a context for graceful shutdown 2. Providing a way to stop the cleanup routine when the application shuts down ```diff -func init() { - go func() { - ticker := time.NewTicker(5 * time.Minute) - defer ticker.Stop() - - for range ticker.C { - searchCache.Cleanup() - } - }() -} +var cleanupDone chan struct{} + +func init() { + cleanupDone = make(chan struct{}) + go func() { + ticker := time.NewTicker(5 * time.Minute) + defer ticker.Stop() + + for { + select { + case <-ticker.C: + searchCache.Cleanup() + case <-cleanupDone: + return + } + } + }() +} + +// StopCacheCleanup stops the cache cleanup goroutine +func StopCacheCleanup() { + if cleanupDone != nil { + close(cleanupDone) + } +} ``` </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used: CodeRabbit UI** **Review profile: CHILL** **Plan: Pro** <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between badafd289996837c6403fbfcc091481017c3ee66 and 07a926902accd889bff095d5b8ecf5b7ecbb0e1a. </details> <details> <summary>📒 Files selected for processing (15)</summary> * `README.md` (3 hunks) * `docker-compose.yml` (1 hunks) * `src/config.toml` (1 hunks) * `src/config/config.go` (6 hunks) * `src/go.mod` (1 hunks) * `src/handlers/docker.go` (17 hunks) * `src/handlers/github.go` (1 hunks) * `src/handlers/imagetar.go` (11 hunks) * `src/handlers/search.go` (1 hunks) * `src/main.go` (5 hunks) * `src/utils/access_control.go` (4 hunks) * `src/utils/cache.go` (6 hunks) * `src/utils/http_client.go` (2 hunks) * `src/utils/proxy_shell.go` (1 hunks) * `src/utils/ratelimiter.go` (7 hunks) </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>🧬 Code Graph Analysis (5)</summary> <details> <summary>src/utils/http_client.go (2)</summary><blockquote> <details> <summary>src/config/config.go (1)</summary> * `GetConfig` (148-184) </details> <details> <summary>src/http_client.go (3)</summary> * `initHTTPClients` (18-58) * `GetGlobalHTTPClient` (61-63) * `GetSearchHTTPClient` (66-68) </details> </blockquote></details> <details> <summary>src/handlers/imagetar.go (3)</summary><blockquote> <details> <summary>src/config/config.go (1)</summary> * `GetConfig` (148-184) </details> <details> <summary>src/utils/http_client.go (1)</summary> * `GetGlobalHTTPClient` (60-62) </details> <details> <summary>src/imagetar.go (9)</summary> * `initDebouncer` (131-136) * `handleSimpleBatchDownload` (657-724) * `initImageTarRoutes` (595-602) * `handleDirectImageDownload` (605-654) * `StreamMultipleImages` (786-884) * `cleanup` (81-87) * `NewDownloadDebouncer` (43-49) * `processImageForBatch` (460-482) * `StreamImageToGin` (223-237) </details> </blockquote></details> <details> <summary>src/utils/access_control.go (1)</summary><blockquote> <details> <summary>src/config/config.go (1)</summary> * `GetConfig` (148-184) </details> </blockquote></details> <details> <summary>src/utils/cache.go (1)</summary><blockquote> <details> <summary>src/config/config.go (1)</summary> * `GetConfig` (148-184) </details> </blockquote></details> <details> <summary>src/handlers/docker.go (5)</summary><blockquote> <details> <summary>src/config/config.go (2)</summary> * `GetConfig` (148-184) * `RegistryMapping` (15-20) </details> <details> <summary>src/utils/http_client.go (1)</summary> * `GetGlobalHTTPClient` (60-62) </details> <details> <summary>src/utils/access_control.go (1)</summary> * `GlobalAccessController` (32-32) </details> <details> <summary>src/utils/cache.go (9)</summary> * `IsCacheEnabled` (132-135) * `BuildManifestCacheKey` (70-73) * `GlobalCache` (28-28) * `WriteCachedResponse` (119-129) * `GetManifestTTL` (75-94) * `IsTokenCacheEnabled` (138-140) * `BuildTokenCacheKey` (66-68) * `WriteTokenResponse` (114-117) * `ExtractTTLFromResponse` (97-112) </details> <details> <summary>src/docker.go (9)</summary> * `proxyDockerAuthOriginal` (388-466) * `ProxyDockerRegistryGin` (85-100) * `handleRegistryRequest` (103-150) * `rewriteAuthHeader` (469-477) * `handleUpstreamManifestRequest` (520-593) * `handleMultiRegistryRequest` (480-517) * `handleManifestRequest` (180-256) * `ProxyDockerAuthGin` (331-338) * `proxyDockerAuthWithCache` (341-370) </details> </blockquote></details> </details><details> <summary>🪛 YAMLlint (1.37.1)</summary> <details> <summary>docker-compose.yml</summary> [error] 8-8: no new line character at the end of file (new-line-at-end-of-file) </details> </details> </details> <details> <summary>🔇 Additional comments (25)</summary><blockquote> <details> <summary>docker-compose.yml (1)</summary> `1-8`: **Confirm indentation convention is now 2 spaces project-wide** You switched this file from 4- to 2-space indents. If other YAML manifests in the repo still use 4 spaces, consider normalising to one style to avoid churn in future diffs. </details> <details> <summary>src/utils/proxy_shell.go (1)</summary> `1-1`: **Package rename looks correct; verify all import paths compile** Moving the file into `package utils` is consistent with the refactor, but make sure all call-sites have updated imports (`hubproxy/utils` or equivalent). A quick `go vet ./...` + `go test ./...` after `go mod tidy` will catch any dangling references. </details> <details> <summary>README.md (2)</summary> `40-41`: **Verify updated install script URL exists** `install-service.sh` → `install.sh` change is fine, but please confirm the new script is pushed to `main` and is executable; broken quick-start links frustrate first-time users. --- `137-149`: **Section renamed to `[access]`; double-check code uses new key** Config struct tags and env-var overrides must match this rename. A mismatch silently falls back to defaults. </details> <details> <summary>src/utils/access_control.go (3)</summary> `1-1`: **LGTM! Package restructuring looks good.** The package name change to `utils` and the addition of the config import are consistent with the modularization efforts in this PR. Also applies to: 6-7 --- `31-31`: **Good improvement: English documentation.** Translating the comment to English improves code accessibility for international contributors. --- `84-84`: **Correct usage of centralized config.** The updates to use `config.GetConfig()` properly leverage the centralized configuration package. Also applies to: 109-109 </details> <details> <summary>src/utils/http_client.go (2)</summary> `1-1`: **Package restructuring is consistent.** The package name change and config import align with the overall modularization approach. Also applies to: 8-9 --- `17-19`: **Properly exported HTTP client functions.** The exported function names follow Go conventions and provide appropriate access to the HTTP clients from other packages. Also applies to: 59-60, 64-65 </details> <details> <summary>src/config/config.go (4)</summary> `1-1`: **Appropriate package name for configuration module.** The `config` package name correctly reflects the module's purpose. --- `28-28`: **Well-implemented H2C support.** The HTTP/2 Cleartext support is properly implemented with: - Opt-in by default (false) - Configuration via TOML and environment variable - Proper error handling for boolean parsing This aligns perfectly with the PR objective. Also applies to: 76-77, 81-81, 225-229 --- `87-88`: **Verify the rate limit configuration changes.** The request limit increased from 20 to 200 (10x increase). The AI summary mentions the period was extended to 3 hours, but the code shows `PeriodHours: 1.0`. Please confirm: 1. Is the 10x rate limit increase intentional and based on actual usage patterns? 2. Should `PeriodHours` be 3.0 instead of 1.0? > Likely an incorrect or invalid review comment. --- `16-20`: **Well-structured configuration types.** The struct definitions with TOML tags are properly implemented for configuration serialization. Also applies to: 25-29 </details> <details> <summary>src/handlers/search.go (2)</summary> `1-17`: **Well-structured handler package.** The package organization and imports are appropriate for a search handler module. --- `279-279`: **Correct usage of search HTTP client.** Properly uses the search-specific HTTP client from utils package with appropriate timeouts for API calls. Also applies to: 432-432 </details> <details> <summary>src/handlers/github.go (2)</summary> `17-30`: **Comprehensive URL pattern matching.** The regex patterns cover all major GitHub-related services and are pre-compiled for performance. --- `93-98`: **Good redirect loop protection.** The implementation properly limits redirects to 20 and returns an appropriate HTTP 508 status code. </details> <details> <summary>src/utils/ratelimiter.go (3)</summary> `1-1`: **LGTM! Package refactoring aligns with modularization.** The package rename from `main` to `utils` and import update to use `hubproxy/config` are consistent with the broader refactoring effort. Also applies to: 12-12 --- `28-28`: **Good optimization for whitelist IP handling.** The addition of a shared `whitelistLimiter` with infinite rate is an efficient approach that: - Reduces memory usage by avoiding individual limiter creation for each whitelist IP - Clearly indicates that whitelist IPs have no rate limiting - Maintains burst size configuration for consistency Also applies to: 85-85, 174-175 --- `45-45`: **Minor: String concatenation style change.** The change from compound assignment to explicit concatenation is functionally equivalent. Both approaches work correctly in this context. Also applies to: 60-60 </details> <details> <summary>src/handlers/imagetar.go (1)</summary> `1-1`: **LGTM! Clean modularization of image streaming functionality.** The refactoring successfully: - Moves functionality to the `handlers` package - Exports initialization functions for external use - Centralizes configuration and HTTP client access through `config` and `utils` packages - Maintains all core functionality while improving modularity Also applies to: 26-27, 123-127, 141-157, 563-566, 576-584 </details> <details> <summary>src/utils/cache.go (1)</summary> `1-1`: **LGTM! Well-structured cache utilities export.** The refactoring properly: - Exports cache types and functions for cross-package use - Creates a global `GlobalCache` instance safely initialized - Centralizes configuration access through the `config` package - Maintains thread-safe operations with the existing sync.Map Also applies to: 12-12, 15-28, 61-140 </details> <details> <summary>src/handlers/docker.go (1)</summary> `1-1`: **LGTM! Comprehensive refactoring of Docker proxy handlers.** The refactoring successfully: - Migrates all configuration access to use `config.GetConfig()` - Updates all cache operations to use `utils.GlobalCache` and related functions - Properly uses `utils.GlobalAccessController` for access control - Updates function signatures to use the exported `config.RegistryMapping` type - Maintains all proxy functionality while improving modularity Also applies to: 15-16, 32-58, 62-80, 122-122, 170-177, 219-223, 299-330, 440-440, 461-467, 513-517 </details> <details> <summary>src/main.go (2)</summary> `12-13`: **H2C support implementation looks good.** The HTTP/2 Cleartext support is properly implemented with: - Conditional enablement based on configuration - Reasonable stream limits and buffer sizes - Appropriate timeout configurations - Clear logging of H2C status Also applies to: 124-150 --- `44-116`: **Excellent modularization of main.go!** The refactoring successfully: - Delegates all initialization to dedicated packages - Removes embedded proxy logic in favor of handler packages - Simplifies the main function to focus on server setup - Improves the health check endpoint with cleaner implementation Also applies to: 173-187 </details> </blockquote></details> </details>

src/handlers/github.go

						
				@@ -0,0 +109,4 @@

							req.Header.Add(key, value)

						}

					}

					req.Header.Del("Host")

coderabbitai[bot] (Migrated from github.com) commented

2025-07-27 12:00:55 +08:00

🛠️ Refactor suggestion

Consider filtering sensitive request headers.

While copying headers, consider filtering out potentially sensitive or problematic headers:

Authorization (unless intentionally proxying auth)
Cookie and Set-Cookie
X-Forwarded-* headers that might conflict

 // 复制请求头
 for key, values := range c.Request.Header {
+    // Skip potentially sensitive headers
+    if key == "Authorization" || key == "Cookie" || strings.HasPrefix(key, "X-Forwarded-") {
+        continue
+    }
     for _, value := range values {
         req.Header.Add(key, value)
     }
 }
 req.Header.Del("Host")

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

	// 复制请求头
	for key, values := range c.Request.Header {
		// Skip potentially sensitive headers
		if key == "Authorization" || key == "Cookie" || strings.HasPrefix(key, "X-Forwarded-") {
			continue
		}
		for _, value := range values {
			req.Header.Add(key, value)
		}
	}
	req.Header.Del("Host")

🤖 Prompt for AI Agents

In src/handlers/github.go around lines 106 to 112, the code copies all request
headers without filtering, which may expose sensitive headers like
Authorization, Cookie, Set-Cookie, and X-Forwarded-* headers. Modify the header
copying loop to skip these sensitive headers by checking the header key and
excluding them from being added to req.Header.

_🛠️ Refactor suggestion_ **Consider filtering sensitive request headers.** While copying headers, consider filtering out potentially sensitive or problematic headers: - `Authorization` (unless intentionally proxying auth) - `Cookie` and `Set-Cookie` - `X-Forwarded-*` headers that might conflict ```diff // 复制请求头 for key, values := range c.Request.Header { + // Skip potentially sensitive headers + if key == "Authorization" || key == "Cookie" || strings.HasPrefix(key, "X-Forwarded-") { + continue + } for _, value := range values { req.Header.Add(key, value) } } req.Header.Del("Host") ```  <details> <summary>📝 Committable suggestion</summary> > ‼️ **IMPORTANT** > Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements. ```suggestion // 复制请求头 for key, values := range c.Request.Header { // Skip potentially sensitive headers if key == "Authorization" || key == "Cookie" || strings.HasPrefix(key, "X-Forwarded-") { continue } for _, value := range values { req.Header.Add(key, value) } } req.Header.Del("Host") ``` </details>  <details> <summary>🤖 Prompt for AI Agents</summary> ``` In src/handlers/github.go around lines 106 to 112, the code copies all request headers without filtering, which may expose sensitive headers like Authorization, Cookie, Set-Cookie, and X-Forwarded-* headers. Modify the header copying loop to skip these sensitive headers by checking the header key and excluding them from being added to req.Header. ``` </details>

src/handlers/github.go

						
				@@ -0,0 +187,4 @@

						if _, err := io.Copy(c.Writer, processedBody); err != nil {

							return

						}

					} else {

coderabbitai[bot] (Migrated from github.com) commented

2025-07-27 12:00:55 +08:00

💡 Verification agent

🧩 Analysis chain

Clarify the purpose of .sh file processing.

The code performs special processing on .sh files using utils.ProcessSmart. Please document:

What modifications are being made to shell scripts?
Are there security implications of modifying executable content?
What's the use case for this feature?

🏁 Script executed:

#!/bin/bash
# Search for the ProcessSmart implementation to understand what it does
ast-grep --pattern 'func ProcessSmart($$$) {
  $$$
}'

Length of output: 55

🏁 Script executed:

#!/bin/bash
# Search for ProcessSmart references and implementation across the repository
rg "ProcessSmart" -n .

Length of output: 337

🏁 Script executed:

#!/bin/bash
# Display the full implementation of ProcessSmart in utils/proxy_shell.go
sed -n '1,200p' src/utils/proxy_shell.go

Length of output: 2472

Please document and safeguard .sh file processing logic

We’ve confirmed that ProcessSmart in utils/proxy_shell.go:

Handles optional gzip by peeking and unwrapping if needed
Reads the entire script into memory (unless >10 MB or no GitHub URLs)
Uses githubRegex to locate all GitHub‐hosted URLs and rewrites each via transformURL(host)
Returns a new io.Reader of the (potentially) modified script

To help future maintainers and ensure safety, please:

• In src/utils/proxy_shell.go (ProcessSmart, lines ~16–54):
– Add a top-level doc comment describing each step (decompression, size check, URL rewrite)
– Call out any edge cases (e.g. very large scripts, scripts without GitHub links)
– Note security considerations around modifying executable content (shebang integrity, unintended regex matches)

• In src/handlers/github.go (lines 150–190):
– Explain the .sh branch’s purpose: why and when you proxy/modify scripts
– Document the impact on downstream clients (chunked responses, URL schemes)

• Add or update unit/integration tests covering:
– A small script with GitHub URLs (verify correct rewrite and valid URL syntax)
– A gzipped script
– A large script (>10 MB) and one without GitHub URLs (ensure no modifications)

This will clarify intent, guard against inadvertent breakage, and surface any security risks.

🤖 Prompt for AI Agents

In src/handlers/github.go around lines 150 to 190, add clear comments explaining
the purpose of the .sh file processing branch, detailing why scripts are proxied
and modified, and how the response headers are adjusted (e.g., chunked transfer
encoding) to inform downstream clients. In src/utils/proxy_shell.go within the
ProcessSmart function (lines ~16–54), add a comprehensive top-level doc comment
describing each processing step: decompression if gzip encoded, size checks to
avoid large memory usage, GitHub URL detection and rewriting, and returning the
modified script reader. Also document edge cases like very large scripts or
scripts without GitHub URLs, and note security considerations such as preserving
shebang integrity and avoiding unintended regex matches. Finally, add or update
unit and integration tests to cover scenarios including small scripts with
GitHub URLs (verifying correct URL rewriting), gzipped scripts, large scripts
over 10 MB, and scripts without GitHub URLs to ensure no modifications occur.

_💡 Verification agent_ <details> <summary>🧩 Analysis chain</summary> **Clarify the purpose of .sh file processing.** The code performs special processing on `.sh` files using `utils.ProcessSmart`. Please document: 1. What modifications are being made to shell scripts? 2. Are there security implications of modifying executable content? 3. What's the use case for this feature? --- 🏁 Script executed: ```shell #!/bin/bash # Search for the ProcessSmart implementation to understand what it does ast-grep --pattern 'func ProcessSmart($$$) { $$$ }' ``` Length of output: 55 --- 🏁 Script executed: ```shell #!/bin/bash # Search for ProcessSmart references and implementation across the repository rg "ProcessSmart" -n . ``` Length of output: 337 --- 🏁 Script executed: ```shell #!/bin/bash # Display the full implementation of ProcessSmart in utils/proxy_shell.go sed -n '1,200p' src/utils/proxy_shell.go ``` Length of output: 2472 --- </details> **Please document and safeguard `.sh` file processing logic** We’ve confirmed that `ProcessSmart` in `utils/proxy_shell.go`: - Handles optional gzip by peeking and unwrapping if needed - Reads the entire script into memory (unless >10 MB or no GitHub URLs) - Uses `githubRegex` to locate all GitHub‐hosted URLs and rewrites each via `transformURL(host)` - Returns a new `io.Reader` of the (potentially) modified script To help future maintainers and ensure safety, please: • In `src/utils/proxy_shell.go` (ProcessSmart, lines ~16–54): – Add a top-level doc comment describing each step (decompression, size check, URL rewrite) – Call out any edge cases (e.g. very large scripts, scripts without GitHub links) – Note security considerations around modifying executable content (shebang integrity, unintended regex matches) • In `src/handlers/github.go` (lines 150–190): – Explain the `.sh` branch’s purpose: why and when you proxy/modify scripts – Document the impact on downstream clients (chunked responses, URL schemes) • Add or update unit/integration tests covering: – A small script with GitHub URLs (verify correct rewrite and valid URL syntax) – A gzipped script – A large script (>10 MB) and one without GitHub URLs (ensure no modifications) This will clarify intent, guard against inadvertent breakage, and surface any security risks. <details> <summary>🤖 Prompt for AI Agents</summary> ``` In src/handlers/github.go around lines 150 to 190, add clear comments explaining the purpose of the .sh file processing branch, detailing why scripts are proxied and modified, and how the response headers are adjusted (e.g., chunked transfer encoding) to inform downstream clients. In src/utils/proxy_shell.go within the ProcessSmart function (lines ~16–54), add a comprehensive top-level doc comment describing each processing step: decompression if gzip encoded, size checks to avoid large memory usage, GitHub URL detection and rewriting, and returning the modified script reader. Also document edge cases like very large scripts or scripts without GitHub URLs, and note security considerations such as preserving shebang integrity and avoiding unintended regex matches. Finally, add or update unit and integration tests to cover scenarios including small scripts with GitHub URLs (verifying correct URL rewriting), gzipped scripts, large scripts over 10 MB, and scripts without GitHub URLs to ensure no modifications occur. ``` </details>

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: 3344/hubproxy#39

优化代码结构，支持h2 #39

Summary by CodeRabbit

Walkthrough

Changes

Sequence Diagram(s)

Estimated code review effort

Poem

Chat

Support

CodeRabbit Commands (Invoked using PR comments)

Other keywords and placeholders

CodeRabbit Configuration File (.coderabbit.yaml)

Documentation and Community

CodeRabbit Configuration File (`.coderabbit.yaml`)