Re: [PATCH] Server PAC file from Squid

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 30 Jun 2010 17:25:49 -0600

On 06/30/2010 05:08 PM, Amos Jeffries wrote:
> On Wed, 30 Jun 2010 16:41:52 -0600, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 06/29/2010 05:04 PM, Amos Jeffries wrote:
>>> On Tue, 29 Jun 2010 14:29:43 -0600, Alex Rousskov
>>> <rousskov_at_measurement-factory.com> wrote:
>>>> On 06/28/2010 10:01 PM, Amos Jeffries wrote:
>>>>> One of the old requests is to server the PAC files directly from
> Squid
>>>>> without needing a local HTTP server just for the one file.
>>>>>
>>>> Big-picture comments:
>>>>
>>>> * IMO, the proposed implementation is a missed opportunity to support
>>>> not just one specific internally stored object but any number of any
>>>> admin-configured internally stored objects. Instead of bloating code
> and
>>>> configuration options with each particular use case, we should add a
>>>> single configuration option to map internal URL paths to locally
> stored
>>>> [error] responses.
>>> I wasn't wanting to go quite that far yet.
>> I do not think there is a big difference in terms of code between what
>> you have done and what should be, IMO, done. However, if we commit your
>> feature, we would have to support it or go through feature withdrawal
>> pains.
>>
>> In fact, I can even simplify it further by initially allowing only one
>> internally stored object. In other words, only one serve_internally
>> squid.conf option would be honored. This will further minimize the
>> amount of extra work needed to go from serving PAC-only to serving any
>> arbitrary file.
>>
>> Later, somebody will add support for multiple serve_internally options,
>> with no negative effect on code or users.
>
> Easy enough to get many supported now with top-down selection and no ACLs.
>
> I'm thinking a generic per-path directive would be simpler than per-file
> which specifies the root directory for static files (or alternatively a
> single file path). Inside that dir the admin can place wpad.dat
> icons/foo.gif etc, etc.

Sure, I was only trying to simplify so that you do not object to
developing something you do not immediately need :-). Directory support
would be great!

> foo_directive /URL-prefix "/file/system/path"
>
> We can add an initial default of the existing datadir and drop the
> special-case pre-loading and service of icons.
>
> What do you think of "static_dir" (as opposed to cache_dir)? meaning a
> directory source for static raw files (as opposed to a directory source for
> cache format objects).

No strong objections, but "static" is a rather overloaded and limiting
term. Besides, if some of those files are processed for macros, they are
not exactly static. I would focus on what Squid is being asked to do,
not on the data it needs to work with:

   serve ... as ...
   preload_and_serve ... ...
   load_and_serve ... ...
   satisfy ... with ...
   short_circuit ... ...
   origin_server_map ... ...
   map ... to ...

Note that I would reverse the order of arguments in the first three options.

${PREFIX} should probably be the default absolute path for relative
directory names, which are often very handy.

HTH,

Alex.
Received on Wed Jun 30 2010 - 23:26:39 MDT

This archive was generated by hypermail 2.2.0 : Thu Jul 01 2010 - 12:00:08 MDT