3

We just launched a new company site for a client. After chasing down some "OMG it looks wrong now!" complaints, we determined that the CSS (and some images, perhaps more) is getting blocked by their firewall. They claim this never happens to them with any other sites, but the effect is consistent across their network, and can't be reproduced outside.

It's not a very big site. Everything is being served from the same server, running a minimal PHP-based CMS, and the client never reported a similar problem during testing from our server. Is this likely to be anything we can fix, or is this solely a problem for their IT?

Improve this question
2
  • Can you describe where the site's hosted and where the firewall is in relation to them and yourselves? And just an FYI, your typical firewall is not doing any application-aware/Layer 7 filtering so it's likely not the firewall. – gravyface Sep 15 '10 at 16:24
  • The site is hosted at a third-party hosting provider, so both the client and us have to go across the WAN to access it. The firewall is an enterprise solution at the client's location, and we learned they do have a content filter in place -- but they're opening a support ticket with Cisco, so I guess that puts us in the clear for now. – user54365 Sep 15 '10 at 19:12
3

Maybe it's just a proxy/caching issue? Could it be that the old site had some static resources with the same name that where heavily cached?

If that's the case the IT department could try to empty the proxy cache. Or, if there is no proxy, tell users to empty their browser cache.

Another thing you could check: maybe some files have the wrong file permissions on your web server and you - being authenticated in some way - don't get the HTTP status 403 Forbidden.

Tell the users to request one of the images directly in the browser's address bar and see what kind of error they get (firewall or web server).

Improve this answer
3
  • Great suggestions, thanks. There weren't any same-path resources, so it doesn't appear to be a cache issue, but the direct-linking to blocked resources seems to be pointing to the enterprise content filter the client is using. They tried adding the IP as an exception, but the problem persisted, so they're opening a ticket with the filter vendor. I guess it's out of our hair for now. – user54365 Sep 15 '10 at 19:19
  • 2
    Well... We solved it. Through the seemingly incongruous remedy of adding the www prefix back into the CMS's base URL, so that now the CSS and everything else are accessed at absolute paths with the www prefix. We had kind of wanted to deprecate the www, but everything still resolves without it, and now everything gets through the filter. I don't have enough networking background to know why this was the case, but hey, now it works. – user54365 Sep 15 '10 at 20:15
  • Glad to hear it. – splattne Sep 15 '10 at 20:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy