Last modified: 2010-02-05 03:38:06 UTC
Created attachment 6796 [details] new $wgSquidResponseLimit configuration directive, with a default value. SquidUpdate uses a hardcoded configuration for the character limit of the Squid server response (SquidUpdate.php, line 143). This makes it hard to integrate MW into custom compilations of Squid, and/or different reverse proxy applications (like Varnish) that might return a different length of result. In this patch, I've created a new configuration directive $wgSquidResponseLimit, and set it to 250 by default (same as the hard-coded value).
Patch committed in r59178.
Reopening since I'm recommending reverting that revision. No compliant HTTP server is going to treat a PURGE like GET, as the original code seems to be implying, so I think that case can just be removed. If you want to detect an error you should look at the response code.
Created attachment 6949 [details] Example of a Varnish HTTP response
I disagree. Varnish allows you to configure whichever output you wish to receive for a PURGE command, and it also adds information about the purge (HTTP response text attached). I realize this might be non-standard, but I believe that keeping MW's code portable (or easy to integrate with different solutions) is a much more meaningful advantage than enforcing standard usage of other products in the market. Another approach would be to design and implement a similiar VarnishUpdate class, but this might be an overkill. What do you think?
I think you're missing the point. The response size limit is a useless paranoid hack for Squid, and is harmful for Varnish, and so should be removed for both. Adding a configuration variable is pointless if the whole code block can be deleted.
Oh, I misunderstood. Great solution.
Done in r62005.
