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