Has anyone been able to successfully configure Octopus 3.x behind a reverse proxy?

Legacy Uncategorised
1

Hello,

I have read the related support thread and referenced GitHub Issue.

My question is not how to configure Octopus or the reverse proxy. We have that in place and working. The issue that we have is that the reverse proxy (ARR in our case) cannot outbound re-write gzip’d responses. Further, Octopus does not appear to respect Accept-Encoding headers (either the lack thereof, or one that explicitly disallows compression (gzip;q=0,deflate;q=0)).

I have read all kinds of threads that talk about how to disable compression at the IIS level (which we cannot do as there are many other servers behind the reverse proxy).

Is it possible to explicitly disable compression via Octopus server configuration? If not, does anyone have a viable solution?

Thanks,

David

2

Hi David,

Thanks for getting in touch. I’m glad you found those threads, they’ve turned out to be a really useful knowledge base for Octopus and ARR. I’ve taken a hunt around like you and found several threads talking about disabling or otherwise modifying the reverse proxy IIS server for the proxy site but as you mentioned this may not be the best option for your situation.

What version of Octopus are you using? The research I’ve done is based on Octopus 3.x, but should still apply for Octopus 2.x.

The logic we apply before we’ll compress the response is based on Simon Cropp’s example:

  • Does the request have an Accept-Encoding header where the value contains gzip (more on this later)
  • Is the response a success (status < 200 || status > 300)
  • Is the response MIME type compatible (css, javascript, html, plain text, xml etc)
  • Is the response actually big enough to be worth compressing (> 4KB)

So from what I’m seeing, if you force the request to be forwarded to Octopus Server without the Accept-Encoding header, or by setting the Accept-Encoding header to blank, Octopus should not encode any responses. You mentioned you’ve already tried forwarding the request without the Accept-Encoding header. I’ve tested this locally directly to Octopus with Fiddler and attached the trace - everything looks as I’d expect - without the Accept-Encoding header, Octopus completely skips the Compression stage and returns the HTML content without encoding. (There is a Transfer-Encoding of chunked)

Regarding using the gzip;q=0,deflate;q=0 to disable encoding the response, you’re right, the simplified logic doesn’t inspect quality so we don’t behave according to the RFC in this regard. This is the first time I’ve seen this behaviour be problemmatic. If this continues to be a problem I’ll raise a GitHub issue to fix.

Hope that helps!
Mike

Accept-Encoding.saz (5 KB)

3

Hey Mike,

Thanks for the response. I somehow missed it until I logged in today to file another issue. I will try to do some more testing to see if I can get it working. I had put the issue down as it wasn’t a showstopper until now when I determined I need to set up a polling tentacle which will require the reverse proxy configuration to work.

4

Ok, got it working!

The trick was to make the reverse proxy (ARR in my case) override the Accept-Encoding request header to be explicitly set to identity.

To do that in ARR, you have to set a server variable (in applicationHost.config) like this:

<serverVariables>
  <set name="HTTP_ACCEPT_ENCODING" value="identity" />
</serverVariables>

You can read about identity here and how to set/override request headers here.

Hope this helps others!

David

5

Hi David,

Thanks for posting your configuration!

Happy Deployments!
Mike