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
This archive was generated by hypermail pre-2.1.9 : Thu Jun 01 2006 - 12:00:01 MDT