- Fixes:
- Minor fix to decompression logic.
Under certain circumstances the decompression logic would sometimes fail with an "unknown compression method" error if the data stream was not preceded with a valid ZLIB header, causing a very small memory leak whenever it would occur. This has now been fixed. Also increased the initial size of the expansion buffer to 32K and upped the maximum to 256K.
- Fix bug in conditional client accept logic causing hang on Win9x systems.
The new conditional client accept logic introduced in the previous 2.7.1 release was not working properly on Windows 9x platforms, causing an error dialog to appear:
OOOPS! setsockopt(SO_CONDITIONAL_ACCEPT) failed on the listening socket WSAENOPROTOOPT: Bad protocol optionwhich caused the system to hang. (In programmer-speak, a deadlock was occurring). This has now been fixed by not specifying the SO_CONDITIONAL_ACCEPT option at all when creating the listening socket since it's not really needed anyway.
- Enhancements:
- Google GWS/2.0 server bug workaround.
In certain situations, Google's "GWS/2.0" server (whatever the heck type of server that is) would sometimes return a response containing invalidly formatted chunk sizes, causing AdCruncher™ to "lose its place" in the data stream.
Since it appeared Google would only do this in the situation where it was trying to chunk a compressed response, new logic was introduced to reject and automatically retry any request that received a chunked compressed response.
In technical terms, the resource (i.e. web page) that was being returned was in pre-compressed (GZIP deflate) format, and the Google server, for whatever reason, decided to "chunk" the response, getting confused at some point along the way. (Please note that the minor bug in the ZLIB deflate logic already mentioned was not at fault. That was just a minor bug I happened to find while researching the Google issue. The Google server really was at fault here, not AdCruncher. There's 's not much any proxy can do when the server it's communicating with mangles the response so badly that there's no way to tell how big the next chunk is.)
Anyway, whenever AdCruncher™ detects such a condition, it immediately aborts the current response and automatically re-requests the same web page again, but this time asking for it in non-compressed format. (The Google server doesn't seem to have any problems chunking non-compressed responses; only compressed ones for some reason. Go figure.)
- ** Important! **
- Modified transparent proxying facility. (fishlsp.dll v2.0, fish.exe v2.0)
The transparent proxying facility was modified to support some new abilities as described in the "Enhancements" section further below.
If you are currently using the transparent proxying facility (or plan to eventually use it), you must ensure that you use the version that came with the version of AdCruncher™ Proxy that you plan to use. You should not mix the two!To use the new features of the new version of the transparent proxying facility, you must use the new version of AdCruncher™ Proxy and vice versa. Prior versions of the transparent proxying facility are incompatible with this new version of AdCruncher™ Proxy, and the new version of the transparent proxying facility will probably not work with older versions of AdCruncher™ Proxy (although I admit I have not personally verified this).
If you wish to use the new features of the new transparent proxying facility provided with this release of AdCruncher™ Proxy, you must first completely uninstall the prior transparent proxying version (and remember, a reboot is required to do so!) and then properly install the new version in its place, being sure to use the correct version of the Transparent Proxying Installation Utility when doing so.It is important that you use the correct version of the Transparent Proxying Installation Utility to perform the uninstall and reinstall. You should uninstall your current transparent proxying facility version using the version of the Transparent Proxying Installation Utility you currently have, and then install the new [transparent proxying facility] version using the new version of the Transparent Proxying Installation Utility that comes with this new release of AdCruncher™ Proxy.
The new version of the Transparent Proxying Installation Utility that comes with this new release of AdCruncher™ Proxy should only be used to install the new version of the transparent proxying facility, and should not be used to install or uninstall prior versions.- Archive file format change.
The internal format of AdCruncher™ Proxy's 'Save' file has changed with this new release due to the inclusion of the new "Acceptable Clients List" feature described in the "Enhancements" section further below.
Your existing AdCruncher™ Proxy files should be opened just fine with the new version and will be automatically converted to the new format as soon as you run AdCruncher™ Proxy for the first time. You should not lose any of your existing information.
However... the new version of AdCruncher™ Proxy's .apf file is incompatible with prior versions. This means that if, for whatever reason, you decide to fall back to running a prior version of AdCruncher™ Proxy, you will have to redefine your proxy all over again if you didn't first save your existing .apf file beforehand.
It is therefore highly recommended that you first copy your existing .apf file to a safe place before installing and running this new version os AdCruncher™ Proxy for the first time (since, as I said, this new version will automatically convert your proxy file to the new format which is incompatible with all prior versions).
- Fixes:
- Fixed a crash that would occasionally occur on SMP (multi-processor) systems and updated the corresponding crash reporting mechanism appropriately.
- Fixed occasional hang at shutdown problem.
Under certain unusual circumstances AdCruncher™ Proxy would sometimes hang whenever it was shutdown. This has now been corrected.
- Fixed potential "file corruption" problem caused by Internet Explorer bug.
When a user downloads a file, the browser (e.g. Internet Explorer) displays a dialog box asking the user what they want to do (e.g. Open the file or Save it, and if "Save it", where to Save it to, etc).
During this time while the browser is waiting for a response from the user (i.e. waiting for them to fill in the dialog box and click the 'OK' button), it stops reading its incoming data stream (i.e. the file download data; i.e. the data that AdCruncher™ Proxy is reading from the remote server and [trying to] send back to the browser).
In eariler versions of AdCruncher™ Proxy, if the user would take longer than 5 seconds to respond to this particular browser download dialog box, AdCruncher™ would mistakenly believe something was wrong (since the browser was no longer responding to its attempts to send response data back to it) and would abort the download by closing the data stream.
Whenever this would happen however, Internet Explorer (and thus the user) would mistakenly believe the download was complete (when in fact it wasn't since it was actually aborted), thereby causing the appearance of "file corruption" when the file would thus be unable to be opened (since it was an incompletely downloaded file; i.e. it wasn't a "complete" file, it was only part of a file).
In my opinion this is actually a bug in Internet Explorer since it should have known that something went wrong since it did not receive all of the data it should have been expecting. The HTTP response headers it receives from AdCruncher™, as per the published standards, states exactly how much data it should be expecting, and if, for whatever reason, it then fails to actually receive the stated amount, it should then know that something went wrong (i.e. that the download had actually failed and thus the file was incomplete and probably corrupt) and thus should have informed the user of that fact. But unfortunately it doesn't do that. Instead, it leads the user to mistakenly believe that the download simply completed very quickly when in actuality it never completed at all.
AdCruncher™ Proxy has now been "fixed" to work around this obvious Internet Explrer bug by simply never timing out while attempting to deliver response data back to the browser. You may now take as long as you wish to respond to the download dialog box, and AdCruncher™ Proxy will simply continue buffering data to eventually be returned back to the browser (once the browser eventually finishes doing whatever it's doing and decides to return back to reading its incoming data stream again) and thus the occasional "file corruption problems" that some users sometimes experienced should now no longer occur.
- Enhancements:
- Transparent proxying on any port on any workstation in LAN. (fishlsp.dll v2.0, fish.exe v2.0) (Improved!)
AdCruncher™ Proxy now allows transparent proxying on any port and may now be installed separately on any workstation on your network. What this means is you now have the ability to transparently route all of your workstations' HTTP traffic to a single AdCruncher™ Proxy instance running on a separate workstation somewhere else on your network.
Previously, transparent proxying only worked on the same workstation that AdCruncher™ Proxy was running on and thus required that AdCruncher™ Proxy also be running on that same workstation.
Now, however, you only need to have AdCruncher™ Proxy running on a single workstation ("the server") and all other workstations on your network ("the clients") can have all of their HTTP traffic automagically routed to your AdCruncher™ Proxy server by simply installing the transparent proxying feature on the client but not AdCruncher™ Proxy itself.
With AdCruncher™ Proxy's transparent proxying facility, no browser configuration is necessary at all on any of your client workstations! Simply install only the Transparent Proxying Facility on each of your client workstations and then AdCruncher™ Proxy itself on your "server" workstation, and all of your client workstations' HTTP accesses will automagically be routed to, and processed by, your AdCruncher™ Proxy server!
- Updated filtering plugin module. (filter.dll v1.3) (Improved!)
The "filter.dll" plugin module has been updated to: 1) disable "jscript" and "vbscript" scripts in addition to the existing "javascript" scripts, 2) detect and disable width=0 and/or height=0 Web Bugs in addition to the existing "width=1 height=1" Web Bugs, and 3) optionally detect and disable "dynsrc=" type images.
- Ability to specify which clients are allowed to connect. (New!)
AdCruncher™ Proxy now supports the ability to limit connections to only specific clients at specific IP addresses.
The "Misc" tab of the Proxy Properties dialog box now allows you to specify the IP addresses of which clients are allowed to connect to AdCruncher™ and use its services. You may add as many entries as you wish and may specify them in either IP address range (from one IP address - to another) or in IP address / subnet mask format.
This list is examined each time a client (browser) attempts to connect to AdCruncher™, and if it is empty (i.e. if it contains no entries at all), the client is allowed to connect just like before. (This is in order to maintain backward compatibility.)
If the list is not empty however (i.e. if it does contain some entries), then the IP address of the client browser attempting to connect must match one of the listed entries. If no match is found, then the client's connection request is rejected (refused), causing it to receive a "WSAECONNREFUSED: Connection refused" response (socket error return code 10061).
Utilizing this feature allows one to deploy AdCruncher™ in a corporate or publicly accessable network environment by allowing you to specify exactly who is, and who is not, allowed to use it. Only those clients whose IP addresses are in your "Allowed to Connect" list will be allowed to connect to AdCruncher™ and use its services.