Nginx as reverse Proxy, remove X-Frame-Options header

Jim Ohlstein jim at ohlste.in
Thu Jan 9 15:21:06 UTC 2014


Hello,

On 1/9/14, 7:24 AM, nano wrote:

[snip]

>
> I share your opinion regarding nginx documentation. It is woeful.
> Particularly when compared to other exemplary open source projects, such
> as Postfix and FreeBSD. My inability to easily transfer my webservers to
> nginx from Apache, due to (my own shortcomings compounded by) terribly
> inadequate documentation, nearly made the transition impossible. Insult
> was only added to injury when, after transferring some sites to the
> recommended nginx, I found very little performance enhancement.
> Admittedly, I am most probably not properly utilizing the application
> and will only see improvements when my own abilities allow it.
> Nevertheless, the documentation needs work. It is prudent to accommodate
> less technically aware users.
>

You may not see much "performance enhancement" if your server was not 
heavily loaded or if it is using PHP to serve static content, such as 
WordPress used to do up until version 3.4 and continues to do on some 
sites that were upgraded from older versions to the current version. 
Also, if you are running a PHP daemon and a MySQL server on the same 
server as you run nginx, they may contribute more to server load than 
does nginx. Optimizing them, especially MySQL, may give you significant 
"performance enhancement". I mention WordPress because you link to a 
WordPress site in your signature. Since your domain was first registered 
in November and since you only have a few posts most of which are 
rudimentary, I am going to doubt that you don't have a lot of traffic. 
Alexa does not even have data on your site yet, it's so new. Plus using 
a self signed certificate and creating SSL links on your home page - 
http://bsdbox.co - give the big red page on Chrome. I have no desire to 
add an exception for a two month old domain. Spring for $4.99/year at 
https://www.cheapssls.com/domain-only.html and get a PositiveSSL 
certificate.

The shortcomings are yours indeed. The documentation is for people who 
understand the concepts and is not meant to be a replacement for a "for 
Dummies" book. I believe that (almost) every directive is covered. If 
you do not understand what the directives mean, there are many ways to 
figure it out. In such a case, Google is your friend.

Comparing nginx documentation to FreeBSD documentation is a bit 
unrealistic. FreeBSD documentation is written by volunteers of which 
there are dozens if not hundreds. The entire project is a community 
effort. Despite that, some is out of date. For instance, look at 
http://www5.us.freebsd.org/doc/handbook/svn-mirrors.html. Do you see 
svn0.eu.FreeBSD.org listed there, or its fingerprint? There may be other 
servers missing as well. I have found many other examples but that's the 
first that comes to mind.

Anyone who wants to *volunteer* to improve the documentation should do 
so. I'm sure the devs would at least look at any provided patches.

Of course, you can always create a community effort of your own and 
organize your own wiki or alternate set of documentation. Or perhaps you 
can apply for a job at Nginx.com to work on upgrading the documentation 
to your standards.

The original purpose of the wiki was to serve as English documentation 
when there was little to none. Sure, it had a bit more hand holding, but 
it really has become superfluous at least in terms of providing up to 
date documentation, at least IMMHO.


-- 
Jim Ohlstein



More information about the nginx mailing list