<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 04/11/2015 11:00, Amos Jeffries a
      écrit :<br>
    </div>
    <blockquote cite="mid:5639D745.20205@treenet.co.nz" type="cite">
      <pre wrap="">On 4/11/2015 12:48 p.m., Marcus Kool wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">I suspect that the problem is that you redirect a HTTPS-based URL to an
HTTP URL and Squid does not like that.

Marcus
</pre>
      </blockquote>
    </blockquote>
    To give it a try in that direction I now redirect to an https
    server. And I get :<br>
    <p>The following error was encountered while trying to retrieve the
      URL: <a href="https://https/*">https://https/*</a></p>
    <blockquote id="error">
      <p><b>Unable to determine IP address from host name <q>https</q></b></p>
    </blockquote>
    <p>The DNS server returned:</p>
    <blockquote id="data">
      <pre>Name Error: The domain name does not exist.</pre>
    </blockquote>
    <br>
    Moreover this would leads sometimes to HTTP-based URL to an HTTPS
    URL and I don't know how much squid likes it either.<br>
    <br>
    <blockquote cite="mid:5639D745.20205@treenet.co.nz" type="cite">
      <pre wrap="">No it is apparently the fact that the domain name being redirected to is
"http".

As in: <a class="moz-txt-link-rfc2396E" href="http://http/something">"http://http/something"</a>

</pre>
    </blockquote>
    I can assure my rewrite_url looks like <a
      class="moz-txt-link-rfc2396E"
      href="https://proxyweb.xxxxx.xxxxx/var1=xxxx&..."><a class="moz-txt-link-rfc2396E" href="https://proxyweb.xxxxx.xxxxx/var1=xxxx&...">"https://proxyweb.xxxxx.xxxxx/var1=xxxx&..."</a></a>.<br>
    <br>
    And this confirm ssl_bump parse this result and get the left part
    before the ":". To play with, I have also redirect to
    "proxyweb.xxxxx.xxxxx:443/var1=xxxx&..." (ie. I removed the <a
      class="moz-txt-link-rfc2396E" href="https://"><a class="moz-txt-link-rfc2396E" href="https://">"https://"</a></a> and
    add a ":443") to force the parsing. Then I don't get this message
    anymore, but Mozilla gets crazy waiting for the ad.doubleclick.net
    certificate and getting the proxyweb.xxxxx.xxxxx one. And of course
    it breaks my SG configuration and can't be production solution. <br>
    <blockquote cite="mid:5639D745.20205@treenet.co.nz" type="cite">
      <pre wrap="">Which brings up the question of why you are using SG to block adverts?

squid.conf:
 acl ads dstdomain .doubleclick.net
 http_access deny ads

Amos


</pre>
    </blockquote>
    I don't use SG to specificaly block adverts, I use it to block 90 %
    of the web. Here it's just an example with ads but it could be with
    so much other things...<br>
    <br>
    I just want to try make SG and ssl_bump live together.<br>
    <br>
    Is this possible to have a rule like "if it has been rewrite then
    don't try to ssl_bump"?<br>
    <br>
    Regards, EG<br>
  </body>
</html>