Issue 6626 - Document the rewrite filter option

pages/filters.html

Index: pages/filters.html
===================================================================
--- a/pages/filters.html
+++ b/pages/filters.html
@@ -176,16 +176,19 @@
       {{s75 <code><fix>donottrack</fix></code> — for any address matching a blocking rule with
       this option and not matching any exception rules with this option a
       <a href="http://donottrack.us/">Do-Not-Track header</a> will be sent (requires
       Adblock Plus 1.3.5 or higher).}} {{s76 For backwards compatibility it is recommended
       to use this option in combination with contradicting type options, this will prevent this
       filter from blocking anything in earlier Adblock Plus versions:
       <code><fix>*$donottrack,image,~image</fix></code>}}
     </li>
+    <li>
+      {{rewriteoption Rewrite the URL with the option <code><fix>rewrite=</fix></code>. You may want to create a regular expression filter to perform the rewrite operation. In that case, you can use <code><fix>$n</fix></code> in the rewrite argument, with n being a number between 1 and 100, to insert the n-th parenthesis submatch of the filter regular expression. Anything not explicitly matched by it will be added in the rewritten string. For example <code><fix>/(server.com\/assets\/file.php)\?.*$/$rewrite=$1</fix></code> will strip everything that comes after ".php" and redirects the request to the resulting URL. If there is no query parameter (i.e. no '?'), this filter won't match. The rewrite parameter has the same syntax as JavaScript’s <code><fix>String.prototype.replace()</fix></code> when using a regular expression instead of a substring. If both, a filter with/without <code><fix>$rewrite</fix></code> option matches, the behavior is undefined, i.e. the request might either be blocked or redirected. (Adblock Plus 3.2 or higher required.)}}

[Manish Jethani, 2018/05/10 02:47:39]

We should probably also mention about the requirement that the rewritten URL
should also be of the same origin.

If we're supporting relative URLs (we are as I see it), we can mention that here
as well, but then I also wonder if that's an unnecessary detail that can be
skipped in the documentation.

+    </li>
   </ul>
 
   <h4 id="regexps">{{s77 Using regular expressions}}</h4>
 
   <p>{{s79 If you want even more control about what your filters match and what they don't match, you can use regular expressions. For example the filter <code><fix>/banner\d+/</fix></code> will match <code><fix>banner123</fix></code> and <code><fix>banner321</fix></code> but not <code><fix>banners</fix></code>. You can check out <a href="{{s79-link https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Regular_Expressions#Writing_a_Regular_Expression_Pattern}}">documentation on regular expressions</a> to learn how to write them.}}</p>
 
   <p>{{s80 <em>Note</em>: For performance reasons it is recommended not to use regular expressions if they can be avoided.}}</p>