--- /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>
+&nbsp;
+</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>
+&nbsp;
+</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>
+&nbsp;
+</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>
+&nbsp;
+</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 &#8212; 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>
+&nbsp;
+</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>