Eventually, one or two of our customers complained about this button not working. This was puzzling since it didn't affect the vast majority of our customers. Screenshots from the customers' machines showed no errors or gave any clue as to what was broken. We had a hunch it might have something to do with security settings but had no way to verify that or reproduce the behaviour on our end. For the time being we just gave up, as we were already considering doing away with the pop-up anyway.
Out of curiosity I wanted to know what would happen if that special header didn't make it to the browser. I fired up Fiddler and replaced our server's response with a version with Spring's headers removed. I clicked on the button and - nothing happened! I was pretty happy that I figured out a way to reproduce the problem but I still wasn't sure this was actually the cause. Because why would anyone want to filter HTTP headers?
Which really only leaves the question of 'Why?' It's understandable that non-IT companies with a small IT staff just rely on the default settings of whatever firewall package they bought. But as a developer of said firewall, what security do I gain by filtering response headers? I can see how filtering specific request headers makes sense at least in obscuring the internal network to the outside. But what harm could possibly come in a response header that couldn't otherwise also come via one of the white-listed headers or just plain via the response body?
Oh, well. There's a ticket in the SWF JIRA and it might be worth a look if you're using Webflow.