Ask HN: What to do if the firewall removes all new HTTP response header fields? | Hacker News Reader

Ask HN: What to do if the firewall removes all new HTTP response header fields?

7 pointsstesch12 comments

A few months ago our company got a new firewall (WatchGuard). It removes every HTTP response header field not in RFC 2616 (HTTP 1.1, June 1999). Maybe even more.

This includes CORS headers which makes it impossible to see the real fonts on a website that uses hosted web fonts like Google fonts.

JIRA was behaving strangely because of missing headers.

And now the evaluation of Drupal 8 went bad because AJAX requests need the header X-Drupal-Ajax-Token: 1.

The admins aren't idiots and they aren't ignoring the users. We see web fonts again and JIRA works like before.

But we are now a bit traumatized. I realized that the web isn't functioning the way I imagined it. Browser vendors and the W3C have made many new features after 1999 that benefit security and speed. But they use new header fields. Content management systems and web development frameworks rely on some X- header fields for features and security.

And I can't rely on these header fields to be available in the browser because the user could be in a network behind such a restrictive firewall. And maybe in a network with administrators who don't care.

What does this mean for future web development work? There's no "we need all headers we send to be available" in the requirements of our tools. Because everybody thinks that all header fields always get delivered. And when you find a CMS that is OK today, it could be breaking everything after a minor update.

Do I need to write everything by hand again? Back to 1999? No new features (including WebSockets, HTTP/2, …)?

You need to get a new firewall. A firewall that breaks the web is a broken firewall.

And what do I do with all the other firewalls in other companies? I was told that a lot of bigger companies in Germany use the WatchGuard firewall. And probably on default settings.

I can't use Drupal 8 for web projects because of this. I don't know if this is a good or bad thing in this case because I hadn't the chance to evaluate it, yet.

And all the other options need to get checked for the same problems. Any CMS without "special" HTTP response fields could get some in the next update.

I'm feeling a bit lost right now. (Programming since 1984.)

Everybody and their grandmother seems to be building/using their own x-header field. It's just a matter of time before an x-header or combination of x-headers becomes a real threat vector. I think there should be some level of additional 'standard' headers (yea, cue XKCD "and now we have 16 standards".

Our inspection firewall logs and dumps unknown x-'s like yours does. We meet once a month to go through them and either deny or clear them. Like your admins, if someone says "Astroscript" isn't working someone will dig into it.

X-headers are not the way to do data passing. There are other ways to make that happen other than creating new headers.

This is very common. In general inventing your own headers as a sideband channel is a bad idea. It's not just firewalls - many proxies do this too. Just put your metadata in the body or URL instead.

FYI here is the Drupal issue queue entry for this. https://www.drupal.org/node/2580191 .

Still open and currently Drupal 8.2 is targeted. The version I tried to evaluate was 8.0.6.

There's got to be a way to configure this firewall to prevent the removal of the headers. It sounds like someone in your IT dept. just configured it in an aggressive manner (perhaps the default). I have no specific experience with Watchguard, but this is almost certainly the case. How big of a company are we talking about?

> impossible to see the real fonts on a website that uses hosted web fonts like Google fonts.

Feature, not a bug.

I block webfonts voluntarily, but there are some sites I have to allow them for because they use icon fonts and the page is unintelligible without them. So saying the unilateral blocking of webfonts is a "feature, not a bug" seems a bit short-sighted.

It's a huge strain on a development and QA team to ensure that every contingency (disabled JS, blocked content, etc) has a fallback. Once you go down that rabbit hole you end up supporting a lot of outdated browsers as well.

This is actually why a lot of people are using HTTPS.

https://www.howtoforge.com/filtering-https-traffic-with-squi...

Reply on news.ycombinator.com