Re: [PATCH] Server PAC file from Squid

On Wed, 30 Jun 2010 17:25:49 -0600, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> 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:
>

Okay. local_file_dir seems to still fit better then.

Well, with the internal server we are not strictly forced to use the error
handling component to process files for macros. Doing the macro processing
would be an added-extra or these directives.

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

Aye definitely. Don't want to break out of pseudo-jail.

Amos
Received on Wed Jun 30 2010 - 23:40:45 MDT