Bug 2899: Restore lost rfc1738_unescape() data type
Data type was converted to char from int during recent upgrades.
On unix systems char is unsigned making the safety checks fail on build.
This reverts the type back to a usable signed int, no logic changes.
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..
projects / thirdparty / squid.git / log
