Different scenarios in a reverse proxy environment

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Different scenarios in a reverse proxy environment

Emilio Casbas
The reverseproxy documentation
(http://wiki.squid-cache.org/SquidFaq/ReverseProxy)
explain different situations with their corresponding squid configuration:

- Domain based virtual host support.
- Different requests to different backend web servers.
- Mapping different URLs to different backend servers.


But what about

- Different requests to different directorys on the same web server.
- Mapping different URLs to different directorys on the same web server.

Would it be realiable or correct do this task with squid? or
Would it be better do it on the backend web server?


Thanks
Emilio C.




Reply | Threaded
Open this post in threaded view
|

Re: Different scenarios in a reverse proxy environment

Jeff Pang-6
2007/7/4, Emilio Casbas <[hidden email]>:
> But what about
>
> - Different requests to different directorys on the same web server.
> - Mapping different URLs to different directorys on the same web server.
>

This is based on original server's virtual hosts config,squid just
take the common setting for reverse proxy,like,

cache_peer 12.34.56.78       parent    80  0  no-query originserver name=CCTV
acl service_icctv dstdomain d1.cctv.com
cache_peer_access CCTV allow service_icctv

acl service_wcctv dstdomain d2.cctv.com
cache_peer_access CCTV allow service_wcctv

acl service_lcctv dstdomain d3.cctv.com
cache_peer_access CCTV allow service_lcctv
Reply | Threaded
Open this post in threaded view
|

Re: Different scenarios in a reverse proxy environment

Amos Jeffries
Administrator
In reply to this post by Emilio Casbas
Emilio Casbas wrote:

> The reverseproxy documentation
> (http://wiki.squid-cache.org/SquidFaq/ReverseProxy)
> explain different situations with their corresponding squid configuration:
>
> - Domain based virtual host support.
> - Different requests to different backend web servers.
> - Mapping different URLs to different backend servers.
>
>
> But what about
>
> - Different requests to different directorys on the same web server.
> - Mapping different URLs to different directorys on the same web server.
>
> Would it be realiable or correct do this task with squid? or
> Would it be better do it on the backend web server?

Um, Squid handles HTTP. There are no such thing as 'directories' in HTTP.

Closest it comes is URL-mapping. The webserver is _always_ how URL are
converted to directories. With a redirector squid can change one URL to
another, webserver has to determine where the content comes from after
that if not already cached by squid.

If you mean same content from two URI, squid can't handle that without
outside help (yet).


Amos
Reply | Threaded
Open this post in threaded view
|

Re: Different scenarios in a reverse proxy environment

Emilio Casbas
In reply to this post by Jeff Pang-6
Jeff Pang escribió:

> 2007/7/4, Emilio Casbas <[hidden email]>:
>> But what about
>>
>> - Different requests to different directorys on the same web server.
>> - Mapping different URLs to different directorys on the same web server.
>>
>
> This is based on original server's virtual hosts config,squid just
> take the common setting for reverse proxy,like,
>
> cache_peer 12.34.56.78       parent    80  0  no-query originserver
> name=CCTV
> acl service_icctv dstdomain d1.cctv.com
> cache_peer_access CCTV allow service_icctv
>
> acl service_wcctv dstdomain d2.cctv.com
> cache_peer_access CCTV allow service_wcctv
>
> acl service_lcctv dstdomain d3.cctv.com
> cache_peer_access CCTV allow service_lcctv
>

I think this example would be redundant, We could achive the same
objective with:

cache_peer 12.34.56.78       parent    80  0  no-query originserver
name=CCTV

acl service_cctv dstdomain .cctv.com
cache_peer_access CCTV allow service_cctv

Various cache_peer_access will have sense with different cache_peer
or with different permission.


Thanks
Emilio C.
Reply | Threaded
Open this post in threaded view
|

Re: Different scenarios in a reverse proxy environment

Jeff Pang-6
2007/7/5, Emilio Casbas <[hidden email]>:

>
> I think this example would be redundant, We could achive the same
> objective with:
>
> cache_peer 12.34.56.78       parent    80  0  no-query originserver
> name=CCTV
>
> acl service_cctv dstdomain .cctv.com
> cache_peer_access CCTV allow service_cctv
>

No.This site of cctv.com has lots of virtual hosts,and those virtual
hosts are located in different original servers.So for us the
statement of 'dstdomain .cctv.com' is not useful at all.
Reply | Threaded
Open this post in threaded view
|

Re: Different scenarios in a reverse proxy environment

Amos Jeffries
Administrator
> 2007/7/5, Emilio Casbas <[hidden email]>:
>>
>> I think this example would be redundant, We could achive the same
>> objective with:
>>
>> cache_peer 12.34.56.78       parent    80  0  no-query originserver
>> name=CCTV
>>
>> acl service_cctv dstdomain .cctv.com
>> cache_peer_access CCTV allow service_cctv
>>
>
> No.This site of cctv.com has lots of virtual hosts,and those virtual
> hosts are located in different original servers.So for us the
> statement of 'dstdomain .cctv.com' is not useful at all.

You should still be able to condense the *_access lines down to a single
instance. Like so:

acl service_cctv dstdomain d1.cctv.com
acl service_cctv dstdomain d2.cctv.com
acl service_cctv dstdomain d3.cctv.com
cache_peer_access CCTV allow service_cctv

With a different acl name for each distinct-origin set of virtual hosts.


Amos