ons 2006-05-03 klockan 11:47 -0400 skrev Sketch: > The problem arises when squid is doing the SSL business and only talks > to the origin server in http. To the apache server, everything is > http, you can see how this would loop: Request -> https -> squid -> > http -> origin server -> http -> squid -> etc.. Yes, and this is what it's designed for. To answer your original question you can use the myport ACL to tell difference between requests accepted on different ports. This way you can deny http access to resources which must be accessed via https and with the help of deny_info you can even make an automatic redirect to https if desired. > Can quid 2.5 be configured as a pass through for https, and leave the > ssl layer stuff to the origin server *without* using a redirector? If this is really what you want then you should publish the HTTPS port of your webserver directly on the Internet via NAT or similar. There is no benefit of having the proxy in the middle if you want the SSL connection to go the whole way back to the web server as the proxy then can not do anything at all with the traffic except forwarding it as it is without inspection to the backend webserver. The benefit of terminating the SSL at the reverse proxy is that the web server then does not need to handle the SSL and can focus on it's primary business of serving content. It also allows caching of the content in the reverse proxy, further reducing the load on the backend web server. The drawback is like you have noticed that the web server isn't as aware that the real URL the client requested was a https URL as the request to the web server was a http url. Regards Henrik
Attachment:
signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel
