documentation rebuild

        <td>Adjust the size of the proxy response field buffer. The buffer size

            should be at least the size of the largest expected header size from

            a proxied response. Setting the value to 0 will use the system

            default of 8192 bytes.

            default of 8192 bytes.<br />

        Available in Apache HTTP Server 2.4.34 and later.

    </td></tr>

    <tr><td>keepalive</td>

        <td>Off</td>

    environment variables will not exist when this interpolation happens,

    so you may still have to resort to <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>

    for complex rules.  Also note that interpolation is not supported

    within the scheme portion of a URL.  Dynamic determination of the

    scheme can be accomplished with <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> as in the

    following example.</p>

    within the scheme/hostname/port portion of a URL. Dynamic determination of

    those fields can be accomplished with <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>.

    The following example describes how to use <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>

    to dynamically set the scheme to http or https:</p>

    <pre class="prettyprint lang-config">RewriteEngine On

    and causes them to substitute the value of an environment

    variable <code>varname</code> for the string <code>${varname}</code>

    in configuration directives if the <var>interpolate</var> option is set.</p>

    <p>Keep this turned off (for server performance) unless you need it!</p>

    <p>The scheme/hostname/port portion of <code class="directive">ProxyPass</code> cannot

    contain variables, please consider using <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> instead.</p>

    <p>Keep this turned off (for server performance) unless you need it!

    Adding variables to <code class="directive">ProxyPass</code> for example may lead to

    using the default mod_proxy's workers configured (that don't allow any fine

    tuning like connections reuse, etc..).</p>

</div>

<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">

<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>

<!-- English Revision: 1832294 -->

<!-- English Revision: 1832294:1834203 (outdated) -->

<!-- French translation : Lucien GENTIS -->

<!-- Reviewed by : Vincent Deffontaines -->

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">

<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>

<!-- English Revision: 344971:1832294 (outdated) -->

<!-- English Revision: 344971:1834203 (outdated) -->

<!--

 Licensed to the Apache Software Foundation (ASF) under one or more

  <variants>

    <variant>en</variant>

    <variant>fr</variant>

    <variant outdated="yes">fr</variant>

    <variant outdated="yes">ja</variant>

  </variants>

</metafile>

<p>This module provides an output filter to rewrite HTML links in a

proxy situation, to ensure that links work for users outside the proxy.

It serves the same purpose as Apache's ProxyPassReverse directive does

It serves the same purpose as Apache's <code class="directive"><a href="../mod/mod_proxy.html#proxypassreverse">ProxyPassReverse</a></code> directive does

for HTTP headers, and is an essential component of a reverse proxy.</p>

<p>For example, if a company has an application server at

<code>www.example.com</code>, they may wish to provide a gateway to the

application server at <code>http://www.example.com/appserver/</code>.

When the application server links to itself, those links need to be

rewritten to work through the gateway. mod_proxy_html serves to rewrite

rewritten to work through the gateway. <code class="module"><a href="../mod/mod_proxy_html.html">mod_proxy_html</a></code> serves to rewrite

<code>&lt;a href="http://appserver.example.com/foo/bar.html"&gt;foobar&lt;/a&gt;</code> to

<code>&lt;a href="http://www.example.com/appserver/foo/bar.html"&gt;foobar&lt;/a&gt;</code>

making it accessible from outside.</p>

<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Sets the buffer size increment for buffering inline scripts and

stylesheets.</td></tr>

<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>ProxyHTMLBufSize <var>bytes</var></code></td></tr>

<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>ProxyHTMLBufSize 8192</code></td></tr>

<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host, directory</td></tr>

<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Base</td></tr>

<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_proxy_html</td></tr>

for earlier 2.x versions</td></tr>

</table>

<p>In order to parse non-HTML content (stylesheets and scripts) embedded

in HTML documents, mod_proxy_html

in HTML documents, <code class="module"><a href="../mod/mod_proxy_html.html">mod_proxy_html</a></code>

has to read the entire script or stylesheet into a buffer.  This buffer will

be expanded as necessary to hold the largest script or stylesheet in a page,

in increments of <var>bytes</var> as set by this directive.</p>

HTML or XHTML syntax is used for output.   Note that the format of the

documents coming from the backend server is immaterial: the parser will

deal with it automatically.  If the optional second argument is set to

"Legacy", documents will be declared "Transitional", an option that may

<code>Legacy</code>, documents will be declared "Transitional", an option that may

be necessary if you are proxying pre-1998 content or working with defective

authoring/publishing tools.</p>

<p>In the second form, it will insert your own FPI.  The optional second