Skip to content

Docs: Clarified http_access scope w.r.t. X.509 AIA #2490

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rousskov wants to merge 1 commit into from
+25 −4
Closed

Docs: Clarified http_access scope w.r.t. X.509 AIA #2490

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 25 additions & 4 deletions src/cf.data.pre
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1514,8 +1514,16 @@ ENDIF
# Matches transaction's initiator [fast]
#
# Supported initiators are:
# certificate-fetching: matches transactions fetching
# a missing intermediate TLS certificate
#
# certificate-fetching: Matches internal transactions fetching a missing
# intermediate TLS certificate. These transactions have a
# Squid-generated request for a URL extracted from the Authority
# Information Access X.509 certificate extension (AIA; RFC 5280).
# These transactions are not associated with client-to-Squid
# connections but go through the usual post-parsing request processing
# steps, including `http_access` controls and `cache_peer` selection.
# Squid has no built-in AIA-specific access or forwarding rules.
#
# cache-digest: matches transactions fetching Cache Digests
# from a cache_peer
# htcp: matches HTCP requests from peers
Expand Down Expand Up @@ -1927,11 +1935,24 @@ LOC: Config.accessList.http
DEFAULT_IF_NONE: deny all
DEFAULT_DOC: Deny, unless rules exist in squid.conf.
DOC_START
Allowing or Denying access based on defined access lists
Controls HTTP and FTP requests access to this Squid instance.

@yadij yadij Sep 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would phrase that more like:

Suggested change
Controls HTTP and FTP requests access to this Squid instance.
Controls whether Squid is allowed to process an HTTP(S) or FTP request message.

@rousskov rousskov Sep 11, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not like my "controls access" version1, but I dislike proposed "allowed to process" variation even more because parsing the request, denying access to that request, and responding to that denied request while obeying deny_info settings (among many other actions!) is all request "processing". We need a more specific word.

Footnotes

  1. Because my version repeats the same "access" word that is already present in the directive name instead of helping a reader unfamiliar with access controls (or a reader with weak English skills) by using a different word that the reader may recognize. ↩

@kinkie kinkie Sep 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's ship it. Done is better than perfect


To allow or deny a message received on an HTTP, HTTPS, or FTP port:
http_access allow|deny [!]aclname ...

This directive applies to parsed requests received on an `http_port`,
`https_port`, or `ftp_port`, fake HTTP CONNECT requests representing
intercepted TLS connections (see `ssl_bump` directive, where available), and
internally-generated X.509 certificate-fetching requests (look for "AIA" in
`transaction_initiator` ACL documentation).

This directive does not apply to requests received from a REQMOD adaptation
service. Use `adapted_http_access` directive to control those requests.

This directive does not apply to internally-generated Cache Digests and
NetDB `cache_peer` requests. Those requests are deemed allowed when enabled
by the corresponding `cache_peer` configuration (they are enabled by
default; see `no-digest` and `no-netdb-exchange` options).

NOTE on default values:

If there are no "access" lines present, the default is to deny
Expand Down
Loading