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

[nano]

On 10/01/2014 4:33 AM, Jim Ohlstein wrote:
> Hello,
>
> On 1/9/14, 12:14 PM, nano wrote:
>> On 10/01/2014 2:21 AM, Jim Ohlstein wrote:
>>> 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".
>>
>> Thanks, Jim, for the suggestions. I may look into optimizing MySQL at a
>> later date.
>
> Going to copy someone else's procedures and write another "tutorial"?
>

I will record the procedure that results in a successful mission. That 
typically involves documenting steps taken from a variety of sources, as 
finding one that works without requiring changes is not commonplace. If 
you have any resources, please feel free to provide them.

>>
>>> 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.
>>>
>>
>> That domain only hosts a personal blog documenting FreeBSD procedures,
>> and SOHO resource for colleagues, family and friends; in fact, the
>> server is still running Apache and is not relevant to my observations
>> pertaining to increased performance, or lack of, in transferring to
>> nginx on other sites. Further, I have no desire to satisfy your trust
>> concerns. My concern is to secure my own sensitive traffic. Moreover,
>> the paradigm of entrusting third parties is foolish and highly
>> susceptible to exploitation, but this, too, is irrelevant. Thank you for
>> your concern and advice; however, I will not be purchasing a
>> "PositiveSSL certificate".
>
> Whatever. You put a link in your signature and *very* rudimentary (and
> somewhat incorrect) "tutorials" in your blog.
>

Please, feel free to highlight what is incorrect, Jim. I would be happy 
to make corrections.

> In fact, on December 20, 2013 you wrote:
>
> "I recently decided to build my first FreeBSD box. First order of
> business: roll my own Apache server to host my ownCloud service. I also
> decided to stand up this WordPress site to document my progress. Mostly
> for posterity’s sake; this way, I have tried-and-tested data to
> reference during future UNIX operations. “Why should I […]"
>

As I said in the paragraph you quote above: "personal blog documenting 
FreeBSD procedures." I find it useful to record my progress. If it helps 
somebody else, that is good.

> Learn something about being a sysadmin before writing "tutorials".
>

I hope to continue learning. Please, feel free to contribute in any way 
you like.

> Anyway, opinions are like assholes. Everybody has one. Yours just
> happens to be wrong.
>

If that is your opinion. Good for you. Like you say, "everybody has one."

>>
>>> 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.
>>>
>>
>> I have no doubt, and iterated, my inadequacies affect my
>> (mis)understanding of the documentation. Similarly, I remarked on the
>> utility of alternative resources; found through Google. If you have some
>> "for Dummies" resources, please feel free to provide them. That would be
>> good.
>>
>>> 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.
>>>
>>
>> It is analogous, as is the comparison to Postfix documentation. I did
>> not claim FreeBSD literature is absent error, but that it is simply more
>> comprehensive and accommodates "Dummies". If nginx chooses to cater for
>> "for people who understand the concepts and is not meant to be a
>> replacement for a 'for Dummies' book", that is the prerogative of the
>> maintainers and developers of nginx documentation.
>
> See above.
>
>>
>>> 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.
>>>
>>
>> I am certain there are people who value and appreciate the project
>> enough that will choose to contribute. When the values and objectives of
>> a project comport with my own, I often choose to contribute how I can;
>> such as, deploying Tor exit nodes, documenting up-to-date, basic
>> procedures, or making monetary donations to the FreeBSD Foundation. This
>> is a nice quality of open source communities. The good ones thrive, the
>> less valued do not.
>>
>>> The original purpose of the wiki was to serve as English documentation
>>> when there was little to none.
>>
>> I am sure that multimillion dollar donations will contribute to further
>> improvements.
>
> I'm not aware of any "multimillion dollar donations" but maybe you are.
> Commercial funding is not a "donation".
>

Then, that multimillion dollar funding will surely help.

>>
>>> 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.
>>>
>>>
>>
>> You are entitled to your opinion, as am I. Your advice will be
>> considered. Thank you, Jim.
>
> Again, see above.
>
>>
>
> Peace out.
>

Likewise.

-- 
syn.bsdbox.co