Problem
When a push or fetch is blocked at the `/info/refs` discovery phase by a URL allow/deny rule, the client receives a bare HTTP 403 with no response body:
```
fatal: unable to access 'http://localhost:8080/proxy/github.com/owner/repo.git/': The requested URL returned error: 403
```
The developer has no way to know whether this is:
- An authentication failure
- A deny rule explicitly blocking the repo
- No allow rule configured for this repo
- A misconfigured proxy
Root cause
`UrlRuleAggregateFilter.applyInfoRefsRules()` calls `response.sendError(provider.getBlockedInfoRefsStatus())` with no message and no body. The git smart HTTP client renders any 4xx/5xx on the `/info/refs` request as the generic `The requested URL returned error: NNN` message.
Compare this to the push/fetch operation path, where `rejectAndSendError()` formats a proper git sideband error with a title and actionable message (e.g. "Fetch Blocked - Repository Not Allowed — Contact an administrator to add this repository to the allow rules").
Expected behaviour
The HTTP response for a blocked `/info/refs` request should include a plain-text body that git will surface to the user, distinguishing between:
- Denied — "This repository has been explicitly denied by an administrator."
- NotAllowed — "This repository is not in the allow list. Contact an administrator."
`HttpServletResponse.sendError(int, String)` passes a message that most servlet containers (including Jetty) include in the response body and that git will display when it encounters a non-200 on `/info/refs`.
Suggested fix
Replace bare `response.sendError(status)` calls in `applyInfoRefsRules()` with `response.sendError(status, reason)` where `reason` is a short human-readable string matching the evaluated rule outcome.
Problem
When a push or fetch is blocked at the `/info/refs` discovery phase by a URL allow/deny rule, the client receives a bare HTTP 403 with no response body:
```
fatal: unable to access 'http://localhost:8080/proxy/github.com/owner/repo.git/': The requested URL returned error: 403
```
The developer has no way to know whether this is:
Root cause
`UrlRuleAggregateFilter.applyInfoRefsRules()` calls `response.sendError(provider.getBlockedInfoRefsStatus())` with no message and no body. The git smart HTTP client renders any 4xx/5xx on the `/info/refs` request as the generic `The requested URL returned error: NNN` message.
Compare this to the push/fetch operation path, where `rejectAndSendError()` formats a proper git sideband error with a title and actionable message (e.g. "Fetch Blocked - Repository Not Allowed — Contact an administrator to add this repository to the allow rules").
Expected behaviour
The HTTP response for a blocked `/info/refs` request should include a plain-text body that git will surface to the user, distinguishing between:
`HttpServletResponse.sendError(int, String)` passes a message that most servlet containers (including Jetty) include in the response body and that git will display when it encounters a non-200 on `/info/refs`.
Suggested fix
Replace bare `response.sendError(status)` calls in `applyInfoRefsRules()` with `response.sendError(status, reason)` where `reason` is a short human-readable string matching the evaluated rule outcome.