Mercurial > hg > nginx-site
changeset 196:aafe530e7d6f
- Added faq/ and more q&a as previously agreed
author | Andrey Alexeev <andrew@nginx.com> |
---|---|
date | Wed, 23 Nov 2011 15:32:04 +0000 |
parents | e83a59eee5cf |
children | 241c9db1f3f4 |
files | xml/en/docs/faq/accept_failed.xml xml/en/docs/faq/chunked_encoding_from_backend.xml xml/en/docs/faq/daemon_master_process_off.xml xml/en/docs/faq/license_copyright.xml xml/en/docs/faq/variables_in_config.xml |
diffstat | 5 files changed, 218 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /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 @@ +<!DOCTYPE article SYSTEM "../../../dtd/article.dtd"> + +<article name="What does the following error mean: + accept() failed (53: Software caused connection abort) + while accepting new connection on 0.0.0.0:80 ?" + link="/en/docs/faq/accept_failed.html" + lang="en"> + +<section> + +<para> +<initial>Q:</initial> +What does the following error mean: "accept() failed (53: +Software caused connection abort) while accepting new +connection on 0.0.0.0:80"? +</para> + +<para> + +</para> + +<para> +<initial>A:</initial> +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. +</para> + +</section> + +</article>
--- /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 @@ +<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd"> + +<article name="Why nginx doesn't handle chunked encoding + responses from my backend properly?" + link="/en/docs/faq/chunked_encoding_from_backend.html" + lang="en"> + +<section> + +<para> +<initial>Q:</initial> +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 + +<programlisting> +47 +{"error":"query error","message":"Parameter(s) missing: user,password"} +0 +</programlisting> + +</para> + +<para> + +</para> + +<para> +<initial>A:</initial> +Your backend violates HTTP/1.0 specification (see +<a href="http://tools.ietf.org/html/rfc2616#section-3.6">RFC 2616, +"3.6 Transfer Codings"</a> +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. +</para> + +</section> + +</article>
--- /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 @@ +<!DOCTYPE article SYSTEM "../../../dtd/article.dtd"> + +<article name="Can I run nginx with daemon off or + master_process off settings + in a production environment?" + link="/en/docs/faq/daemon_master_process_off.html" + lang="en"> + +<section> + +<para> +<initial>Q:</initial> +Can I run nginx with daemon off or master_process off settings +in a production environment? +</para> + +<para> + +</para> + +<para> +<initial>A:</initial> +First of all, both "daemon on|off" and "master_process on|off" directives were +intended to be used for nginx code develpment. +</para> + +<para> +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. +</para> + +<para> +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. +</para> + +</section> + +</article> \ No newline at end of file
--- /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 @@ +<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd"> + +<article name="How can nginx copyright be acknowledged + when using nginx as part of a proprietary + software distibution?" + link="/en/docs/faq/license_copyright.html" + lang="en"> + +<section> + +<para> +<initial>Q:</initial> +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? +</para> + +<para> + +</para> + +<para> +<initial>A:</initial> +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. +</para> + +<programlisting> +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. +</programlisting> + +</section> + +</article>
--- /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 @@ +<!DOCTYPE article SYSTEM "../../../dtd/article.dtd"> + +<article name="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?" + link="/en/docs/faq/variables_in_config.html" + lang="en"> + +<section> + +<para> +<initial>Q:</initial> +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? +</para> + +<para> + +</para> + +<para> +<initial>A:</initial> +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. +</para> + +</section> + +</article>