Re: [squid-users] Connection: close

On Monday 20 May 2002 01:35, Warrick FitzGerald wrote:
> Thanks for the quick response Henrik,
>
> - I don't understand what are the persistent_connections are for
> then, if squid is only HTTP/1.0 based at the moment ?

There is also persistent connections in HTTP/1.0. Not in the official
standard, a industry standard set by Netscape and supported by almost
all browsers and web servers. Negotiated using "Connection:
keep-alive" to keep the connection persistent (as opposed to
HTTP/1.1's "Connection: close" to not keep it persistent).

> Still my primary problem is trying to cache authenticated content.
> One thought I had (hair brain scheme I know) is to use the proxy
> authentication features in a reverse proxy environment. I have
> never worked with squid in any situation except for reverse so I
> would just like to see if this is even an option.

Squid will cache authenticated content if marked as cacheable. This
is done by the "Cache-control: public" header. May be combined with
other "Cache-control" directives to further control the details of
how the URL is cached.

> Could I use the "authenticate_program" option to run an external
> process which queries the origin server to see if the client should
> be authenticated. Does squid send the Realm, username and password
> to the external program (Login and Password are obvious, but what
> about realm ?)

There currently is only one realm, the one you have set Squid to
respond with.

Authentication can be combined with any other access controls for a
very detailes access control of who may access what.

Normally some trickery is required to enable authentication in
accelerators. This to protect people running transparent proxies from
inadvertly enabling the feature thinking it can be used in
transparent proxies.. See acl.c (hint: search for the words AUTH and
ACCEL on the same line)

> The content I have behind squid is VERY cpu intensive and if there
> is any way that I can cache this content and only deliver it to
> authenticated clients I would be very happy, and I'm sure my client
> would be to. (They all receive identical content but I need to
> ensure that only authenticated people can access the content).

Sounds like a good case for moving the authentication to Squid.

-- 
MARA Systems AB, Giving you basic free Squid support
Your source of advanced web reverse proxying solutions
http://www.marasystems.com/products/