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

[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.xtreamlab.net/pipermail/ootb-infra/attachments/20150610/611549b8/attachment.html>