# HG changeset patch # User Andrey Alexeev # Date 1322062324 0 # Node ID aafe530e7d6fd5716a5f79fd6d63c9342535de81 # Parent e83a59eee5cfff41145ab4a6f905b1d26b2d388e - Added faq/ and more q&a as previously agreed diff -r e83a59eee5cf -r aafe530e7d6f xml/en/docs/faq/accept_failed.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/en/docs/faq/accept_failed.xml Wed Nov 23 15:32:04 2011 +0000 @@ -0,0 +1,35 @@ + + +
+ +
+ + +Q: +What does the following error mean: "accept() failed (53: +Software caused connection abort) while accepting new +connection on 0.0.0.0:80"? + + + +  + + + +A: +Such errors stem from the connections that the clients managed +to close before nginx was able to process them. For instance, this can +happen in a situation when the user didn't wait for a page +heavily populated with graphics to load fully, and clicked on +a different link. In this case user's browser would close all of +the prior connections which aren't longer necessary. It is a non-critical +error. + + +
+ +
diff -r e83a59eee5cf -r aafe530e7d6f xml/en/docs/faq/chunked_encoding_from_backend.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/en/docs/faq/chunked_encoding_from_backend.xml Wed Nov 23 15:32:04 2011 +0000 @@ -0,0 +1,43 @@ + + +
+ +
+ + +Q: +My backend server appears to send HTTP/1.0 responses using +chunked encoding but nginx doesn't handle it correctly. +For instance, I'm using nginx as a frontend to my node.js +application and instead of pure JSON from backend nginx +returns something framed in decimal numbers like + + +47 +{"error":"query error","message":"Parameter(s) missing: user,password"} +0 + + + + + +  + + + +A: +Your backend violates HTTP/1.0 specification (see +RFC 2616, +"3.6 Transfer Codings" +The "chunked" transfer-codings must not be used with HTTP/1.0. +You'd need to either fix your backend application or upgrade +to nginx version 1.1.4 and newer, where an additional code +was introduced to handle such erratic backend behavior. + + +
+ +
diff -r e83a59eee5cf -r aafe530e7d6f xml/en/docs/faq/daemon_master_process_off.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/en/docs/faq/daemon_master_process_off.xml Wed Nov 23 15:32:04 2011 +0000 @@ -0,0 +1,44 @@ + + +
+ +
+ + +Q: +Can I run nginx with daemon off or master_process off settings +in a production environment? + + + +  + + + +A: +First of all, both "daemon on|off" and "master_process on|off" directives were +intended to be used for nginx code develpment. + + + +While many people use daemon off in production it wasn't really meant for +that. Since version 1.0.9 it is now quite safe to run nginx in production +with daemon off, though. Bear in mind that non-stop upgrade is not an +option with daemon off. + + + +In a development environment, using master_process off, nginx can run in +the foreground without the master process and can be terminated simply +with ^C (SIGINT). This is somewhat similar to running Apache with +an 'X' commandline option. However you should never run nginx in production +with master_process off. + + +
+ +
\ No newline at end of file diff -r e83a59eee5cf -r aafe530e7d6f xml/en/docs/faq/license_copyright.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/en/docs/faq/license_copyright.xml Wed Nov 23 15:32:04 2011 +0000 @@ -0,0 +1,59 @@ + + +
+ +
+ + +Q: +I'd like to use nginx distribution as part of my proprietary +software package. How can nginx copyright be acknowledged +when using nginx as part of a proprietary software distibution? + + + +  + + + +A: +The section of text below should be added to your license descriptions. +Also, if your build of nginx includes any of the following 3rd party +products: zlib, PCRE, OpenSSL — it's worth including their +copyright acknowledgements and disclaimers as well. + + + +This product contains software provided by Nginx, Inc. and its contributors. + +Copyright (c) 2002-2011, Igor Sysoev. All rights reserved. +Copyright (c) 2011, Nginx, Inc. All rights reserved. + +Redistribution and use in source and binary forms, with or without modification, are +permitted provided that the following conditions are met: +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. + +THIS SOFTWARE IS PROVIDED BY NGINX, INC. AND CONTRIBUTORS AS IS AND +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +ARE DISCLAIMED. IN NO EVENT SHALL NGINX, INC. OR CONTRIBUTORS BE LIABLE +FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +SUCH DAMAGE. + + +
+ +
diff -r e83a59eee5cf -r aafe530e7d6f xml/en/docs/faq/variables_in_config.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/en/docs/faq/variables_in_config.xml Wed Nov 23 15:32:04 2011 +0000 @@ -0,0 +1,37 @@ + + +
+ +
+ + +Q: +Is there a proper way to use nginx variables to make sections of +the configuration shorter, using them as macros for making +parts of configuration work as templates? + + + +  + + + +A: +Variables should not be used as template macros. Variables are +evaluated in the run-time during the processing of each +request, so they are rather costly compared to plain static +configuration. Using variables to store static strings is also +a bad idea. Instead, a macro expansion should be used to +generate configs more easily and it can be done with the +external tools, e.g. sed + make or any other common template +mechanism. + + +
+ +