diff --git a/docs/applications/project-management/how-to-install-and-configure-redmine-on-ubuntu-16-04.md b/docs/applications/project-management/how-to-install-and-configure-redmine-on-ubuntu-16-04.md index b3f47cef1fe..504708be00b 100644 --- a/docs/applications/project-management/how-to-install-and-configure-redmine-on-ubuntu-16-04.md +++ b/docs/applications/project-management/how-to-install-and-configure-redmine-on-ubuntu-16-04.md @@ -2,7 +2,7 @@ author: name: Angel email: docs@linode.com -description: 'This guide shows how to install and set up Redmine, a free and open-source project management web application, written using Ruby on Rails, that is is cross-platform and cross-database.' +description: 'This guide shows how to install and set up Redmine, a free and open-source project management web application, written using Ruby on Rails, that is cross-platform and cross-database.' keywords: ["nginx", "ubuntu", "redmine"] license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)' published: 2017-09-14 diff --git a/docs/development/python/use-scrapy-to-extract-data-from-html-tags.md b/docs/development/python/use-scrapy-to-extract-data-from-html-tags.md index a244ff6286f..5947310b750 100644 --- a/docs/development/python/use-scrapy-to-extract-data-from-html-tags.md +++ b/docs/development/python/use-scrapy-to-extract-data-from-html-tags.md @@ -201,7 +201,7 @@ class LinkCheckerSpider(scrapy.Spider): ### Add Request Meta Information -The Spider will traverse links in queue recursively. When parsing a downloaded page, it does not have any information about the previously parsed pages such as which page was linking the the new one. To pass more information to the `parse` method, Scrapy provides a `Request.meta()` method that attaches some key/value pairs to the request. They are available in the response object in the `parse()` method. +The Spider will traverse links in queue recursively. When parsing a downloaded page, it does not have any information about the previously parsed pages such as which page was linking the new one. To pass more information to the `parse` method, Scrapy provides a `Request.meta()` method that attaches some key/value pairs to the request. They are available in the response object in the `parse()` method. The meta information is used for two purposes: @@ -525,4 +525,4 @@ Scrapy provides a telnet interface on port 6023 to monitor a running spider. The 6. Stop your scraping; - engine.stop() \ No newline at end of file + engine.stop() diff --git a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-centos-5.md b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-centos-5.md index f25fb54696f..87e448a8af7 100644 --- a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-centos-5.md +++ b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-centos-5.md @@ -115,7 +115,7 @@ RewriteRule ^/wiki/(.*)$ http://app.example.com/mediawiki/$1 [proxy] In the first group we present three examples of requests for specific types of files that will be proxied to various directories in the `http://static.example.com/` host. Note that the entire contents of the parenthetical (e.g. `(.*)` in this case) will be passed to the proxy host. If you do not capture the extension of a request in the regular expression, you must add it to the rewritten location. Using the first example, assuming these rewrite rules are in the `example.com` virtual host, requests for `http://example.com/toggle.js` and `http://example.com/blog/js/functions.js` are passed to `http://static.example.com/javascript/toggle.js` and `http://static.example.com/javascript/blog/js/functions.js`. -In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php`. However a request for `http://example.com/wordpress/style.css` would not be be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. +In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php`. However a request for `http://example.com/wordpress/style.css` would not be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. In order to ensure that your rewrite rules function as predicted, keep in mind the following: diff --git a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-debian-5-lenny.md b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-debian-5-lenny.md index c0834523d64..35eb4635ec1 100644 --- a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-debian-5-lenny.md +++ b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-debian-5-lenny.md @@ -119,7 +119,7 @@ RewriteRule ^/wiki/(.*)$ http://app.example.com/mediawiki/$1 [proxy] In the first group we present three examples of requests for specific types of files that will be proxied to various directories in the `http://static.example.com/` host. Note that the entire contents of the parenthetical (e.g. `(.*)` in this case) will be passed to the proxy host. If you do not capture the extension of a request in the regular expression, you must add it to the rewritten location. Using the first example, assuming these rewrite rules are in the `example.com` virtual host, a requests for `http://example.com/toggle.js` and `http://example.com/blog/js/functions.js` are passed to `http://static.example.com/javascript/toggle.js` and `http://static.example.com/javascript/blog/js/functions.js` respectively. -In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. +In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. In order to ensure that your rewrite rules function as predicted, keep in mind the following: diff --git a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-fedora-12.md b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-fedora-12.md index b664eb53fc8..ef430b09174 100644 --- a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-fedora-12.md +++ b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-fedora-12.md @@ -113,7 +113,7 @@ RewriteRule ^/wiki/(.*)$ http://app.example.com/mediawiki/$1 [proxy] In the first group we present three examples of requests for specific types of files that will be proxied to various directories in the `http://static.example.com/` host. Note that the entire contents of the parenthetical (e.g. `(.*)` in this case) will be passed to the proxy host. If you do not capture the extension of a request in the regular expression, you must add it to the rewritten location. Using the first example, assuming these rewrite rules are in the `example.com` virtual host, a requests for `http://example.com/toggle.js` and `http://example.com/blog/js/functions.js` are passed to `http://static.example.com/javascript/toggle.js` and `http://static.example.com/javascript/blog/js/functions.js` -In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. +In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. In order to ensure that your rewrite rules function as predicted, keep in mind the following: diff --git a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-fedora-14.md b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-fedora-14.md index fad3d961520..9f3ac73e9f1 100644 --- a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-fedora-14.md +++ b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-fedora-14.md @@ -113,7 +113,7 @@ RewriteRule ^/wiki/(.*)$ http://app.example.com/mediawiki/$1 [proxy] In the first group we present three examples of requests for specific types of files that will be proxied to various directories in the `http://static.example.com/` host. Note that the entire contents of the parenthetical (e.g. `(.*)` in this case) will be passed to the proxy host. If you do not capture the extension of a request in the regular expression, you must add it to the rewritten location. Using the first example, assuming these rewrite rules are in the `example.com` virtual host, a requests for `http://example.com/toggle.js` and `http://example.com/blog/js/functions.js` are passed to `http://static.example.com/javascript/toggle.js` and `http://static.example.com/javascript/blog/js/functions.js` -In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. +In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. In order to ensure that your rewrite rules function as predicted, keep in mind the following: diff --git a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-10-04-lucid.md b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-10-04-lucid.md index 93934b7fcf6..2828b022f71 100644 --- a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-10-04-lucid.md +++ b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-10-04-lucid.md @@ -121,7 +121,7 @@ RewriteRule ^/wiki/(.*)$ http://app.example.com/mediawiki/$1 [proxy] In the first group we present three examples of requests for specific types of files that will be proxied to various directories in the `http://static.example.com/` host. Note that the entire contents of the parenthetical (e.g. `(.*)` in this case) will be passed to the proxy host. If you do not capture the extension of a request in the regular expression, you must add it to the rewritten location. Using the first example, assuming these rewrite rules are in the `example.com` virtual host, a requests for `http://example.com/toggle.js` and `http://example.com/blog/js/functions.js` are passed to `http://static.example.com/javascript/toggle.js` and `http://static.example.com/javascript/blog/js/functions.js` respectively. -In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. +In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. In order to ensure that your rewrite rules function as predicted, keep in mind the following: diff --git a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-10-10-maverick.md b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-10-10-maverick.md index f3df2b7b227..ae1c115bf9c 100644 --- a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-10-10-maverick.md +++ b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-10-10-maverick.md @@ -121,7 +121,7 @@ RewriteRule ^/wiki/(.*)$ http://app.example.com/mediawiki/$1 [proxy] In the first group we present three examples of requests for specific types of files that will be proxied to various directories in the `http://static.example.com/` host. Note that the entire contents of the parenthetical (e.g. `(.*)` in this case) will be passed to the proxy host. If you do not capture the extension of a request in the regular expression, you must add it to the rewritten location. Using the first example, assuming these rewrite rules are in the `example.com` virtual host, a requests for `http://example.com/toggle.js` and `http://example.com/blog/js/functions.js` are passed to `http://static.example.com/javascript/toggle.js` and `http://static.example.com/javascript/blog/js/functions.js` respectively. -In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. +In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. In order to ensure that your rewrite rules function as predicted, keep in mind the following: diff --git a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-12-04-precise-pangolin.md b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-12-04-precise-pangolin.md index 1d863326f5c..b5baa0139b9 100644 --- a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-12-04-precise-pangolin.md +++ b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-12-04-precise-pangolin.md @@ -119,7 +119,7 @@ RewriteRule ^/wiki/(.*)$ http://app.example.com/mediawiki/$1 [proxy] In the first group we present three examples of requests for specific types of files that will be proxied to various directories in the `http://static.example.com/` host. Note that the entire contents of the parenthetical (e.g. `(.*)` in this case) will be passed to the proxy host. If you do not capture the extension of a request in the regular expression, you must add it to the rewritten location. Using the first example, assuming these rewrite rules are in the `example.com` virtual host, a requests for `http://example.com/toggle.js` and `http://example.com/blog/js/functions.js` are passed to `http://static.example.com/javascript/toggle.js` and `http://static.example.com/javascript/blog/js/functions.js` respectively. -In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. +In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. In order to ensure that your rewrite rules function as predicted, keep in mind the following: diff --git a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-9-10-karmic.md b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-9-10-karmic.md index a465c09a2c6..c80a7c79165 100644 --- a/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-9-10-karmic.md +++ b/docs/websites/proxies/using-apache-for-proxy-and-clustering-services-on-ubuntu-9-10-karmic.md @@ -119,7 +119,7 @@ RewriteRule ^/wiki/(.*)$ http://app.example.com/mediawiki/$1 [proxy] In the first group we present three examples of requests for specific types of files that will be proxied to various directories in the `http://static.example.com/` host. Note that the entire contents of the parenthetical (e.g. `(.*)` in this case) will be passed to the proxy host. If you do not capture the extension of a request in the regular expression, you must add it to the rewritten location. Using the first example, assuming these rewrite rules are in the `example.com` virtual host, a requests for `http://example.com/toggle.js` and `http://example.com/blog/js/functions.js` are passed to `http://static.example.com/javascript/toggle.js` and `http://static.example.com/javascript/blog/js/functions.js` respectively. -In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. +In the second group of examples, rather than passing the entire request back to a proxy, we choose to only pass a part of the request. In the first rule of this group, a request for `http://example.com/blog/index.php` would be served from `http://app.example.com/wordpress/index.php` however a request for `http://example.com/wordpress/style.css` would not be passed to `app.example.com`; indeed, given the earlier rules, this request would be passed to `http://static.example.com/styles/wordpress/style.css`. In the second rule in this example, every request for a resource that begins with `http://example.com/wiki/` would be passed to `http://app.example.com/mediawiki/`. With this rewrite rule, both `http://example.com/wiki/index.php` and `http://example.com/wiki/info/about.html` would be rewritten as `http://app.example.com/mediawiki/index.php` and `http://app.example.com/mediawiki/info/about.html`. In order to ensure that your rewrite rules function as predicted, keep in mind the following: