Fixed #26124 -- Added missing code formatting to docs headers.

5 files changed, 28 insertions, 28 deletions

diff --git a/docs/topics/http/middleware.txt b/docs/topics/http/middleware.txt
index 7ffaa9fc32..e84aafa123 100644
--- a/docs/topics/http/middleware.txt
+++ b/docs/topics/http/middleware.txt
@@ -85,8 +85,8 @@ Python class that defines one or more of the following methods:
 
 .. _request-middleware:
 
-``process_request``
--------------------
+``process_request()``
+---------------------
 
 .. method:: process_request(request)
 
@@ -106,8 +106,8 @@ return the result.
 
 .. _view-middleware:
 
-``process_view``
-----------------
+``process_view()``
+------------------
 
 .. method:: process_view(request, view_func, view_args, view_kwargs)
 
@@ -145,8 +145,8 @@ view; it'll apply response middleware to that
 
 .. _template-response-middleware:
 
-``process_template_response``
------------------------------
+``process_template_response()``
+-------------------------------
 
 .. method:: process_template_response(request, response)
 
@@ -172,8 +172,8 @@ includes ``process_template_response()``.
 
 .. _response-middleware:
 
-``process_response``
---------------------
+``process_response()``
+----------------------
 
 .. method:: process_response(request, response)
 
@@ -229,8 +229,8 @@ must test for streaming responses and adjust their behavior accordingly::
 
 .. _exception-middleware:
 
-``process_exception``
----------------------
+``process_exception()``
+-----------------------
 
 .. method:: process_exception(request, exception)
 
@@ -248,8 +248,8 @@ Again, middleware are run in reverse order during the response phase, which
 includes ``process_exception``. If an exception middleware returns a response,
 the middleware classes above that middleware will not be called at all.
 
-``__init__``
-------------
+``__init__()``
+--------------
 
 Most middleware classes won't need an initializer since middleware classes are
 essentially placeholders for the ``process_*`` methods. If you do need some
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index 5dc1bef043..5e7bd74d2b 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -329,7 +329,7 @@ easily available on the internet. Although the cookie session storage signs the
 cookie-stored data to prevent tampering, a :setting:`SECRET_KEY` leak
 immediately escalates to a remote code execution vulnerability.
 
-Bundled Serializers
+Bundled serializers
 ~~~~~~~~~~~~~~~~~~~
 
 .. class:: serializers.JSONSerializer
@@ -359,7 +359,7 @@ Bundled Serializers
 
 .. _custom-serializers:
 
-Write Your Own Serializer
+Write your own serializer
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Note that unlike :class:`~django.contrib.sessions.serializers.PickleSerializer`,
diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
index 7faef87766..af2da254fb 100644
--- a/docs/topics/http/shortcuts.txt
+++ b/docs/topics/http/shortcuts.txt
@@ -12,8 +12,8 @@ The package ``django.shortcuts`` collects helper functions and classes that
 "span" multiple levels of MVC. In other words, these functions/classes
 introduce controlled coupling for convenience's sake.
 
-``render``
-==========
+``render()``
+============
 
 .. function:: render(request, template_name, context=None, content_type=None, status=None, using=None)
 
@@ -81,8 +81,8 @@ This example is equivalent to::
         return HttpResponse(t.render(c, request),
             content_type="application/xhtml+xml")
 
-``render_to_response``
-======================
+``render_to_response()``
+========================
 
 .. function:: render_to_response(template_name, context=None, content_type=None, status=None, using=None)
 
@@ -90,8 +90,8 @@ This example is equivalent to::
    similarly except that it doesn't make the ``request`` available in the
    response. It's not recommended and is likely to be deprecated in the future.
 
-``redirect``
-============
+``redirect()``
+==============
 
 .. function:: redirect(to, permanent=False, *args, **kwargs)
 
@@ -157,8 +157,8 @@ will be returned::
         object = MyModel.objects.get(...)
         return redirect(object, permanent=True)
 
-``get_object_or_404``
-=====================
+``get_object_or_404()``
+=======================
 
 .. function:: get_object_or_404(klass, *args, **kwargs)
 
@@ -230,8 +230,8 @@ Note: As with ``get()``, a
 :class:`~django.core.exceptions.MultipleObjectsReturned` exception
 will be raised if more than one object is found.
 
-``get_list_or_404``
-===================
+``get_list_or_404()``
+=====================
 
 .. function:: get_list_or_404(klass, *args, **kwargs)
 
diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
index 068b91bf60..5555a4a1ab 100644
--- a/docs/topics/http/urls.txt
+++ b/docs/topics/http/urls.txt
@@ -234,8 +234,8 @@ Performance
 Each regular expression in a ``urlpatterns`` is compiled the first time it's
 accessed. This makes the system blazingly fast.
 
-Syntax of the urlpatterns variable
-==================================
+Syntax of the ``urlpatterns`` variable
+======================================
 
 ``urlpatterns`` should be a Python list of :func:`~django.conf.urls.url`
 instances.
diff --git a/docs/topics/http/views.txt b/docs/topics/http/views.txt
index c21012fa64..020c06e090 100644
--- a/docs/topics/http/views.txt
+++ b/docs/topics/http/views.txt
@@ -94,8 +94,8 @@ to create a return class for any status code you like. For example::
 Because 404 errors are by far the most common HTTP error, there's an easier way
 to handle those errors.
 
-The Http404 exception
----------------------
+The ``Http404`` exception
+-------------------------
 
 .. class:: django.http.Http404()