summaryrefslogtreecommitdiff
path: root/docs/narr
diff options
context:
space:
mode:
Diffstat (limited to 'docs/narr')
-rw-r--r--docs/narr/advanced-features.rst4
-rw-r--r--docs/narr/commandline.rst2
-rw-r--r--docs/narr/firstapp.rst4
-rw-r--r--docs/narr/hooks.rst4
-rw-r--r--docs/narr/hybrid.rst2
-rw-r--r--docs/narr/introduction.rst8
-rw-r--r--docs/narr/renderers.rst4
-rw-r--r--docs/narr/security.rst6
-rw-r--r--docs/narr/templates.rst2
-rw-r--r--docs/narr/testing.rst2
-rw-r--r--docs/narr/upgrading.rst2
-rw-r--r--docs/narr/viewconfig.rst2
12 files changed, 22 insertions, 20 deletions
diff --git a/docs/narr/advanced-features.rst b/docs/narr/advanced-features.rst
index 431b4f030..8d99f7291 100644
--- a/docs/narr/advanced-features.rst
+++ b/docs/narr/advanced-features.rst
@@ -84,7 +84,7 @@ Speaking of the :app:`Pyramid` structured :meth:`~pyramid.config.Configurator.in
If you need, you can extend or override the configuration of an existing application by including its configuration in your own and then modifying it.
-For example, if you want to reuse an existing application that already has a bunch of routes, you can just use the ``include`` statement with a ``route_prefix``. All the routes of that application will be availabe, prefixed as you requested:
+For example, if you want to reuse an existing application that already has a bunch of routes, you can just use the ``include`` statement with a ``route_prefix``. All the routes of that application will be available, prefixed as you requested:
.. code-block:: python
:linenos:
@@ -116,7 +116,7 @@ authorization patterns.
Build Trees of Resources
------------------------
-:app:`Pyramid` supports :term:`traversal`, a way of mapping URLs to a concrete :term:`resource tree`. If your application naturally consists of an arbitrary heirarchy of different types of content (like a CMS or a Document Management System), traversal is for you. If you have a requirement for a highly granular security model ("Jane can edit documents in *this* folder, but not *that* one"), traversal can be a powerful approach.
+:app:`Pyramid` supports :term:`traversal`, a way of mapping URLs to a concrete :term:`resource tree`. If your application naturally consists of an arbitrary hierarchy of different types of content (like a CMS or a Document Management System), traversal is for you. If you have a requirement for a highly granular security model ("Jane can edit documents in *this* folder, but not *that* one"), traversal can be a powerful approach.
.. seealso::
diff --git a/docs/narr/commandline.rst b/docs/narr/commandline.rst
index 21b2a0839..0c5189903 100644
--- a/docs/narr/commandline.rst
+++ b/docs/narr/commandline.rst
@@ -452,7 +452,7 @@ For example:
route_and_view_attached / app1.standard_views.route_and_view_attached *
method_conflicts /conflicts app1.standard_conflicts <route mismatch>
multiview /multiview app1.standard_views.multiview GET,PATCH
- not_post /not_post app1.standard_views.multview !POST,*
+ not_post /not_post app1.standard_views.multiview !POST,*
``proutes`` generates a table with four columns: *Name*, *Pattern*, *View*, and
*Method*. The items listed in the Name column are route names, the items
diff --git a/docs/narr/firstapp.rst b/docs/narr/firstapp.rst
index 49d9b467f..9bc79ac1b 100644
--- a/docs/narr/firstapp.rst
+++ b/docs/narr/firstapp.rst
@@ -38,9 +38,9 @@ On Windows:
%VENV%\Scripts\python helloworld.py
This command will not return and nothing will be printed to the console. When
-port 6543 is visited by a browser on the URL ``/hello/world``, the server will
+port 6543 is visited by a browser on the URL ``/``, the server will
simply serve up the text "Hello world!". If your application is running on
-your local system, using `<http://localhost:6543/hello/world>`_ in a browser
+your local system, using `<http://localhost:6543/>`_ in a browser
will show this result.
Each time you visit a URL served by the application in a browser, a logging
diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index 3c02c2653..1ca5c3a6d 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -1335,7 +1335,7 @@ Specifying neither ``over`` nor ``under`` is equivalent to specifying
If all options for ``under`` (or ``over``) cannot be found in the current
configuration, it is an error. If some options are specified purely for
-compatibilty with other tweens, just add a fallback of ``MAIN`` or ``INGRESS``.
+compatibility with other tweens, just add a fallback of ``MAIN`` or ``INGRESS``.
For example, ``under=('someothertween', 'someothertween2', INGRESS)``. This
constraint will require the tween to be located under the ``someothertween``
tween, the ``someothertween2`` tween, and ``INGRESS``. If any of these is not
@@ -1412,7 +1412,7 @@ time.
Displaying Tween Ordering
~~~~~~~~~~~~~~~~~~~~~~~~~
-The ``ptweens`` command-line utility can be used to report the current implict
+The ``ptweens`` command-line utility can be used to report the current implicit
and explicit tween chains used by an application. See
:ref:`displaying_tweens`.
diff --git a/docs/narr/hybrid.rst b/docs/narr/hybrid.rst
index 1238601ed..58c3e82e8 100644
--- a/docs/narr/hybrid.rst
+++ b/docs/narr/hybrid.rst
@@ -495,7 +495,7 @@ the above call to ``request.resource_path`` would generate ``/mysection/``. See
:ref:`virtual_root_support` for more information.
If the route you're trying to use needs simple dynamic part values to be filled
-in to succesfully generate the URL, you can pass these as the ``route_kw``
+in to successfully generate the URL, you can pass these as the ``route_kw``
argument to ``resource_url`` and ``resource_path``. For example, assuming that
the route definition is like so:
diff --git a/docs/narr/introduction.rst b/docs/narr/introduction.rst
index 41a5638e3..f62e28905 100644
--- a/docs/narr/introduction.rst
+++ b/docs/narr/introduction.rst
@@ -35,7 +35,7 @@ Reliability
:app:`Pyramid` is developed conservatively and tested exhaustively. Our motto is: "If it ain't tested, it's broke".
Openness
- As with Python, the :app:`Pyramid` software is distributed under a `permissive open source license <http://repoze.org/license.html>`_.
+ As with Python, the :app:`Pyramid` software is distributed under a `permissive open source license <https://web.archive.org/web/20190401024809/http://repoze.org/license.html>`_.
.. _why_pyramid:
@@ -52,7 +52,7 @@ Modern
Tested
~~~~~~
-Untested code is broken by design. The :app:`Pyramid` community has a strong testing culture and our framework reflects that. Every release of :app:`Pyramid` has 100% statement coverage (as measured by `coverage <https://coverage.readthedocs.io/en/latest/>`_) and 95% decision/condition coverage. (as measured by `instrumental <https://instrumental.readthedocs.io/en/latest/intro.html>`_) It is automatically tested using `Travis <https://travis-ci.org/Pylons/pyramid>`_ and `Jenkins <http://jenkins.pylonsproject.org/job/pyramid/>`_ on supported versions of Python after each commit to its GitHub repository. `Official Pyramid add-ons <https://trypyramid.com/extending-pyramid.html>`_ are held to a similar testing standard.
+Untested code is broken by design. The :app:`Pyramid` community has a strong testing culture and our framework reflects that. Every release of :app:`Pyramid` has 100% statement coverage (as measured by `coverage <https://coverage.readthedocs.io/en/latest/>`_) and 95% decision/condition coverage. (as measured by `instrumental <https://instrumental.readthedocs.io/en/latest/intro.html>`_) It is automatically tested using `Travis <https://travis-ci.org/Pylons/pyramid>`_ and Jenkins on supported versions of Python after each commit to its GitHub repository. `Official Pyramid add-ons <https://trypyramid.com/extending-pyramid.html>`_ are held to a similar testing standard.
We still find bugs in :app:`Pyramid`, but we've noticed we find a lot fewer of them while working on projects with a solid testing regime.
@@ -70,7 +70,7 @@ You can get help quickly with :app:`Pyramid`. It's our goal that no :app:`Pyrami
.. seealso::
- See also our `#pyramid IRC channel <https://webchat.freenode.net/?channels=pyramid>`_, our `pylons-discuss mailing list <https://groups.google.com/forum/#!forum/pylons-discuss>`_, and :ref:`support-and-development`.
+ See also our `#pyramid IRC channel <https://webchat.freenode.net/#pyramid>`_, our `pylons-discuss mailing list <https://groups.google.com/forum/#!forum/pylons-discuss>`_, and :ref:`support-and-development`.
.. _what_makes_pyramid_unique:
@@ -245,7 +245,7 @@ When you use a :term:`renderer` with your view callable, you are freed from need
.. index::
pair: renderer; explicitly calling
- pair: view renderer; explictly calling
+ pair: view renderer; explicitly calling
.. _example_render_to_response_call:
diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index 6b4982e4b..21cfa0497 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -357,9 +357,9 @@ When a view is called that uses a JSONP renderer:
Javscript library AJAX functionality will help you make JSONP requests.
For example, JQuery has a `getJSON function
-<http://api.jquery.com/jQuery.getJSON/>`_, and has equivalent (but more
+<https://api.jquery.com/jQuery.getJSON/>`_, and has equivalent (but more
complicated) functionality in its `ajax function
-<http://api.jquery.com/jQuery.ajax/>`_.
+<https://api.jquery.com/jQuery.ajax/>`_.
For example (JavaScript):
diff --git a/docs/narr/security.rst b/docs/narr/security.rst
index b49958b85..2a7034a19 100644
--- a/docs/narr/security.rst
+++ b/docs/narr/security.rst
@@ -715,7 +715,7 @@ Preventing Cross-Site Request Forgery Attacks
`Cross-site request forgery
<https://en.wikipedia.org/wiki/Cross-site_request_forgery>`_ attacks are a
-phenomenon whereby a user who is logged in to your website might inadvertantly
+phenomenon whereby a user who is logged in to your website might inadvertently
load a URL because it is linked from, or embedded in, an attacker's website.
If the URL is one that may modify or delete data, the consequences can be dire.
@@ -887,7 +887,9 @@ that it matches one of the trusted origins. By default the only trusted origin
is the current host, however additional origins may be configured by setting
``pyramid.csrf_trusted_origins`` to a list of domain names (and ports if they
are non-standard). If a host in the list of domains starts with a ``.`` then
-that will allow all subdomains as well as the domain without the ``.``.
+that will allow all subdomains as well as the domain without the ``.``. If no
+``Referer`` or ``Origin`` header is present in an HTTPS request, the CSRF check
+will fail unless ``allow_no_origin`` is set.
If CSRF checks fail then a :class:`pyramid.exceptions.BadCSRFToken` or
:class:`pyramid.exceptions.BadCSRFOrigin` exception will be raised. This
diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index e5244e1ad..34d9a115c 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -452,7 +452,7 @@ templating languages including the following:
.. _pyramid_chameleon:
https://docs.pylonsproject.org/projects/pyramid-chameleon/en/latest/
-.. _Jinja2: http://jinja.pocoo.org/docs/dev/
+.. _Jinja2: https://jinja.palletsprojects.com/en/2.10.x/
.. _pyramid_jinja2:
https://docs.pylonsproject.org/projects/pyramid-jinja2/en/latest/
diff --git a/docs/narr/testing.rst b/docs/narr/testing.rst
index 8048ca62c..883bb7c7b 100644
--- a/docs/narr/testing.rst
+++ b/docs/narr/testing.rst
@@ -50,7 +50,7 @@ The suggested mechanism for unit and integration testing of a :app:`Pyramid`
application is the Python :mod:`unittest` module. Although this module is
named :mod:`unittest`, it is actually capable of driving both unit and
integration tests. A good :mod:`unittest` tutorial is available within `Dive
-Into Python <http://www.diveintopython.net/unit_testing/index.html>`_ by Mark
+Into Python 3 <https://diveinto.org/python3/unit-testing.html>`_ by Mark
Pilgrim.
:app:`Pyramid` provides a number of facilities that make unit, integration, and
diff --git a/docs/narr/upgrading.rst b/docs/narr/upgrading.rst
index 87e4647c3..af552741c 100644
--- a/docs/narr/upgrading.rst
+++ b/docs/narr/upgrading.rst
@@ -103,7 +103,7 @@ a newer Pyramid release is always to read the :ref:`changelog` to find the
deprecations and removals for each release between the release you're currently
running and the one to which you wish to upgrade. The change history notes
every deprecation within a ``Deprecation`` section and every removal within a
-``Backwards Incompatibilies`` section for each release.
+``Backwards Incompatibilities`` section for each release.
The change history often contains instructions for changing your code to avoid
deprecation warnings and how to change docs-deprecated spellings to newer ones.
diff --git a/docs/narr/viewconfig.rst b/docs/narr/viewconfig.rst
index da2c41409..465477b4d 100644
--- a/docs/narr/viewconfig.rst
+++ b/docs/narr/viewconfig.rst
@@ -196,7 +196,7 @@ Non-Predicate Arguments
``require_csrf``
CSRF checks will affect any request method that is not defined as a "safe"
- method by RFC2616. In pratice this means that GET, HEAD, OPTIONS, and TRACE
+ method by RFC2616. In practice this means that GET, HEAD, OPTIONS, and TRACE
methods will pass untouched and all others methods will require CSRF. This
option is used in combination with the ``pyramid.require_default_csrf``
setting to control which request parameters are checked for CSRF tokens.