[OOTB-infra] misdirecting honeycomb instance (@heiko)

[Heiko Robert]

Martin,
you confuse me. What is/was the intension of your mails? Why are you not 
answering my questions? My intension is to help you getting your isse 
done but receive complaints.
If you already decided to put your VM directly into the internet with a 
dedicated IP you may order another IP and bind it to your VM. I'm not 
the guy trying to convert you but you should be able to explain others 
why this is a good idea ...

Heiko

Am 10.06.2015 um 21:03 schrieb martin at ocretail.com:
> OK I get it I think, the reason I'm getting a redirect error is because
> of not returning that header? OK
> The thing is, I'm not going to add that feature to the next point
> release of honeycomb, perhaps it will be an option in 1.1.0 but right
> now I need to run a production version honeycomb as it is. So I guess
> we're going to have to host it elsewhere, it's a shame we didn't get any
> extra IPs at the time we got the box, as I suggested at the time.
>
>  > On 09 June 2015 at 20:58 Heiko Robert
> <heiko.orderofthebee.info at ecm4u.de> wrote:
>  >
>  >
>  > Hi Martin,
>  >
>  > it's up to you:
>  >
>  > ** using reverse proxy chain **
>  >
>  > we/I could define an additional virtual host in our apache reverse proxy
>  > and make sure the required header attributes are set. No rewrite rules
>  > are set here to allow you max flexibility but SSL cert is requrired on
>  > the upfront apache proxy to handle SSL handshake. You should also make
>  > sure that in your virtual host the proxy headers are handled. What are
>  > you using - apache or nginx?
>  > At the end the tomcat config needs to translate the header variables
>  > back or you set hostname and port the hard way. Do you connect to Tomcat
>  > using http or ajp? In case of http you could define a connector valve to
>  > translate automatically:
>  >
>  > <!-- Connectors for reverse proxy (nginx) terminating SSL -->
>  > <Connector port="8081" address="localhost" URIEncoding="UTF-8"
>  > protocol="HTTP/1.1"
>  > maxThreads="300" connectionTimeout="600000"
>  > maxHttpHeaderSize="32768"
>  > redirectPort="443" disableUploadTimeout="false"
>  > proxyPort="443" scheme="https" secure="false" sslProtocol="TLS"
>  > maxSavePostSize="-1"
>  > />
>  >
>  >
>  > <Valve className="org.apache.catalina.valves.RemoteIpValve"
>  > remoteIpHeader="X-Forwarded-For"
>  > remoteIpProxiesHeader="X-Forwarded-By"
>  > protocolHeader="X-Forwarded-Proto"
>  > />
>  >
>  > where
>  > remoteIpHeader is the client IP header attribute and
>  > remoteIpProxiesHeader is the proxy IPs header attribute
>  >
>  > There is absolutely no reason not to terminate HTTPS but it's just a
>  > decision. Tomcat config has to be touched in any case.
>  >
>  >
>  > ** using port forward **
>  >
>  > Port forwards are IP based and therfore don't support name dependant
>  > resolution on the same IP. Define an unused port number of your choice
>  > and we could forward this port on the firewall to your reverse proxy
>  > port to the VM.
>  >
>  > Make your decision and I can configure or show you how to do it.
>  >
>  > Heiko
>  >
>  > >> Do you have your own reverse proxy components (apache/nginx)?
>  > > Yes that's exactly the issue
>  >
>  > > I just want to know if it is possible to have a virtual host proxy
>  > > without any ssl termination or url rewriting, as our instance already
>  > > handles that.
>  > _______________________________________________
>  > OOTB-infra mailing list
>  > OOTB-infra at xtreamlab.net
>  > http://www.xtreamlab.net/mailman/listinfo/ootb-infra