* merge multiple authenticate and authenticateChildren members from
child classes into the parent AuthUserRequest
* severe circular ref-count links between AuthUser object and
AuthUserRequest. It appears to be unused and causes problems by merely
existing.
* remove entry from client_side unsettign the auth credentials of a
request simply because it was being logged.
The log code woud be better pulling the credentials from the request
directly when needed instead of cloning the text. RefCount in both request
and AuthUser holds the info in place until log output is finished.
But that polish is left for later.
Author: Matthew Morgan <atcs.matthew@gmail.com>
Add acl support to range_offset_limit.
It is being parsed using the same data types as reply_body_max_size,
which means the limit value gets run through parseBytesLine64, and the
acl is optional.
If people are using the old global style of range_offset_limit, they
shouldn't have to do anything to their configs.
getRangeOffsetLimit is now a member of HttpRequest, and it caches it's
value the same way reply_body_max_size does for faster repeat checking.
Author: Alex Rousskov
Modify icap_service_failure_limit option to forget old ICAP errors.
A busy or remote ICAP server may produce a steady but shallow stream of
errors. Any ICAP server may become nearly unusable in a short period of
time, producing a burst of errors. To avoid disabling a generally usable
service, it is important to distinguish these two cases. Just counting
the number of errors and suspending the service after
icap_service_failure_limit is reached often either suspends the service
in both cases or never suspends it at all, depending on the option
value.
One way to distinguish a large burst of errors from a steady but shallow
error stream is to forget about old errors. The icap_service_failure_limit
option modified to instructs Squid to ignore errors that
are "too old" to be counted as a part of a burst.
Another way to look at this feature is to say that the modified
icap_service_failure_limit limits the ICAP error _rate_. For example,
# suspend service usage after 10 failures in 5 seconds:
icap_service_failure_limit 10 in 5 seconds
Squid does not remember every transaction error that occurred within the
allowed "oldest error" time period. That would be result in a precise
but too expensive implementation, especially during error bursts on a
busy server. Instead, Squid divides the period in ten slots, counts the
number of errors that occurred in each slot, and forget the oldest
slot(s) as needed. Thus, the algorithm has about 90% precision as far as
timing of the failures is concerned. That 90% precision ought to be good
enough for any deployment.
Amos Jeffries [Sun, 21 Mar 2010 03:08:26 +0000 (21:08 -0600)]
Compat: Shuffle squid.h portability definitions into libcompat
* Improves and shuffles the memory allocator and string buffer protection
* Fixing many of the unsafe string buffer handling helpers
* removing several duplicated hacks already in libcompat
* Adds NetBSD portability file
Amos Jeffries [Tue, 16 Mar 2010 23:53:33 +0000 (12:53 +1300)]
Templates for captive portal proxy configration instructions
Captive portals often have to bounce users to configuration instructions.
Those instructions consist of of how to setup WPAD or manual settings.
These templates allow for a standard and localized instruction set for
better support of mixed language users across any portal.
They are used by adding deny_info ERR_AGENT_... to the configuration.
The ERR_AGENT_CONFIGURE template utilizes visible_hostname and port info
from the responding proxy to display correct configuration details for
the gateway without requiring administrative re-write of the page.
Derived from work by the Mandrivia Project.
TODO:
* some form of CSS agent detection to specialize the instructions.
* add texts for other common agents
Henrik Nordstrom [Mon, 15 Mar 2010 23:21:14 +0000 (00:21 +0100)]
As reported some weeks ago ufsdump fails to link on the upcoming Fedora
13 release due to linking issues, and as reported by Amos the same
linking issues is now also seen on Debian since somewhere between March
2 - 5.
While investigating this I found the following conclusions
- We are not actually installing ufsdump
- The dependencies between the Squid libraries are very non-obvious,
with libraries depending on plain object files and other strange things.
- The ufsdump linkage issues is somehow triggered by the libraries
including objects needing symbols from objects not included in that link
- Those failing library objects are not actually needed by ufsdump.
Linking succeeds if repeatedly removing each reported failing object
from the squid libraries.
- If the libraries were shared libraries then linking would fail on all
systems
The issue have been identified, or actually two separate issues. What is
yet unclear is what is the proper solution..
- Inline operator overloading causing indeterministic linkage,
resulting in seemingly unneeded sub modules being pulled in "at random".
Most notably this is seen with our custom new operation (which btw is
duplicated in two places: src/SquidNew.cc and include/SquidNew.h)
- The current Squid libraries have very unclear dependencies with no
clean boundaries, resulting in linking failure when the above happens..
Fix stale=true on digest requests with unknown nonce
The nonce staleness check only worked if the stale nonce had not yet
been garbage collected, often resulting in incorrect stale=false
responses and resulting auth popups when using digest auth.
Note: this fix is different from how it's done in squid-2 where fixHeader
is called on all schemes in such conditions but only the active one with
and auth_user_request. Not entirely sure why that is done, but commit
message says something about Negotiate authentication.
Amos Jeffries [Fri, 5 Mar 2010 02:07:24 +0000 (15:07 +1300)]
Rationalize the default httpd_accel_surrogate_id
Prevents more posibilities for data leakage by making the default
surrogate ID based on visible_hostname (public FQDN for the proxy).
Now that Surrogate_Capability: header is sent by default in accelerator
environments it makes more sense to default it to a value fairly unique
or at least restricted to that local administrative domain.
When visible_hostname is setup correctly (either automatic or manual)
each stand-alone squid install should have a unique ID. Groups of proxies
sharing work for a domain should also be by default sharing an ID and
thus sharing the override behavior.
When visible_hostname is unavailable it will retain the old default of
'unset-id'.
projects / thirdparty / squid.git / log
