Polish Invalid === in Docs

docs/manual/src/docs/asciidoc/_includes/servlet/architecture/filters.adoc

@@ -20,7 +20,7 @@ In this instance the `Filter` will typically write the `HttpServletResponse`.
 The power of the `Filter` comes from the `FilterChain` that is passed into it.
 
 .`FilterChain` Usage Example
-===
+====
 [source,java]
 ----
 public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
@@ -29,6 +29,6 @@ public void doFilter(ServletRequest request, ServletResponse response, FilterCha
     // do something after the rest of the application
 }
 ----
-===
+====
 
 Since a `Filter` only impacts downstream ``Filter``s and the `Servlet`, the order each `Filter` is invoked is extremely important.

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/logout.adoc

@@ -51,10 +51,10 @@ For more information, please consult the {security-api-url}org/springframework/s
 This is a shortcut for adding a `CookieClearingLogoutHandler` explicitly.
 
 [NOTE]
-===
+====
 Logouts can of course also be configured using the XML Namespace notation.
 Please see the documentation for the <<nsa-logout, logout element>> in the Spring Security XML Namespace section for further details.
-===
+====
 
 Generally, in order to customize logout functionality, you can add
 `{security-api-url}org/springframework/security/web/authentication/logout/LogoutHandler.html[LogoutHandler]`

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/session-management.adoc

@@ -29,7 +29,7 @@ You may be able to explicitly delete the JSESSIONID cookie on logging out, for e
 Unfortunately this can't be guaranteed to work with every servlet container, so you will need to test it in your environment
 
 [NOTE]
-===
+====
 If you are running your application behind a proxy, you may also be able to remove the session cookie by configuring the proxy server.
 For example, using Apache HTTPD's mod_headers, the following directive would delete the `JSESSIONID` cookie by expiring it in the response to a logout request (assuming the application is deployed under the path `/tutorial`):
 
@@ -39,7 +39,7 @@ For example, using Apache HTTPD's mod_headers, the following directive would del
 Header always set Set-Cookie "JSESSIONID=;Path=/tutorial;Expires=Thu, 01 Jan 1970 00:00:00 GMT"
 </LocationMatch>
 ----
-===
+====
 
 
 [[ns-concurrent-sessions]]

docs/manual/src/docs/asciidoc/_includes/servlet/authorization/method-security.adoc

@@ -161,16 +161,16 @@ public Account post(Account account, double amount);
 Expression-based annotations are a good choice if you need to define simple rules that go beyond checking the role names against the user's list of authorities.
 
 [NOTE]
-===
+====
 The annotated methods will only be secured for instances which are defined as Spring beans (in the same application context in which method-security is enabled).
 If you want to secure instances which are not created by Spring (using the `new` operator, for example) then you need to use AspectJ.
-===
+====
 
 [NOTE]
-===
+====
 You can enable more than one type of annotation in the same application, but only one type should be used for any interface or class as the behaviour will not be well-defined otherwise.
 If two annotations are found which apply to a particular method, then only one of them will be applied.
-===
+====
 
 [[ns-protect-pointcut]]
 === Adding Security Pointcuts using protect-pointcut

docs/manual/src/docs/asciidoc/_includes/servlet/namespace/index.adoc

@@ -240,11 +240,11 @@ The order of the filters is always strictly enforced when using the namespace.
 When the application context is being created, the filter beans are sorted by the namespace handling code and the standard Spring Security filters each have an alias in the namespace and a well-known position.
 
 [NOTE]
-===
+====
 In previous versions, the sorting took place after the filter instances had been created, during post-processing of the application context.
 In version 3.0+ the sorting is now done at the bean metadata level, before the classes have been instantiated.
 This has implications for how you add your own filters to the stack as the entire filter list must be known during the parsing of the `<http>` element, so the syntax has changed slightly in 3.0.
-===
+====
 
 The filters, aliases and namespace elements/attributes which create the filters are shown in <<filter-stack>>.
 The filters are listed in the order in which they occur in the filter chain.
@@ -347,7 +347,7 @@ The names "FIRST" and "LAST" can be used with the `position` attribute to indica
 
 .Avoiding filter position conflicts
 [TIP]
-===
+====
 
 If you are inserting a custom filter which may occupy the same position as one of the standard filters created by the namespace then it's important that you don't include the namespace versions by mistake.
 Remove any elements which create filters whose functionality you want to replace.
@@ -356,7 +356,7 @@ Note that you can't replace filters which are created by the use of the `<http>`
 Some other filters are added by default, but you can disable them.
 An `AnonymousAuthenticationFilter` is added by default and unless you have <<ns-session-fixation,session-fixation protection>> disabled, a `SessionManagementFilter` will also be added to the filter chain.
 
-===
+====
 
 If you're replacing a namespace filter which requires an authentication entry point (i.e. where the authentication process is triggered by an attempt by an unauthenticated user to access to a secured resource), you will need to add a custom entry point bean too.