On Fri, 23 Jan 2004 [EMAIL PROTECTED] wrote: > Thank you for the reply, but I'm afraid I don't quite understand your > answer. I thought that configuring external DNS to point > 'backend.foo.com'at the squid box would be sufficient to deal with the link > problem. In fact, when I make squid listen to http on 8015, it handles the > links fine. > > It's the squid-to-client redirect from http 8015 to https 443 that I seem > to be having trouble with.
Ok, then I misunderstood you. Most people wanting to run SSL considers any requests jumping over to HTTP as a major security leak and do not want this. Ofcourse you can make Squid send a browser redirect if this is what you prefer. Assuming the two servers are named differently you can simply enable httpd_accel_uses_host_header and then redirect based on the host name, or if you are using Squid-3 things get a little simpler. > I hope you can clarify your point, and perhaps point out a solution other > than modify the application. While I want SSL for a new group of internet > users, I am restricted from changing the application (Oracle 11i self > service) in any way due to impact on internal inside users. The change to use relative or absolute paths in the generated HTML does not affect users, it only makes the application both more efficient as less bytes of HTML code needs to be generated and to work better with reverse proxies as there is less risk of confusion about what the server name, port or protocol is supposed to be. A absolute path is <A HREF="/path/to/file"> while your application today is generating absolute URLs like <A HREF="http://server:port/path/to/file";> To the browser the two are the same while browsing the exact same server, as the first form says this file on the same server you are on now, while the second form says this file on this exact server port and protocol regardless of where you are now. Regards Henrik
