fix footnotes markup

Fixes #3180

docs/manual/src/docs/asciidoc/_includes/servlet/architecture/technical-overview.adoc

@@ -258,7 +258,7 @@ Or you might work for a company that has a legacy proprietary authentication sys
 In situations like this it's quite easy to get Spring Security to work, and still provide authorization capabilities.
 All you need to do is write a filter (or equivalent) that reads the third-party user information from a location, build a Spring Security-specific `Authentication` object, and put it into the `SecurityContextHolder`.
 In this case you also need to think about things which are normally taken care of automatically by the built-in authentication infrastructure.
-For example, you might need to pre-emptively create an HTTP session to <<tech-intro-sec-context-persistence,cache the context between requests>>, before you write the response to the client footnote:[It isn't possible to create a session once the response has been committed.
+For example, you might need to pre-emptively create an HTTP session to <<tech-intro-sec-context-persistence,cache the context between requests>>, before you write the response to the client footnote:[It isn't possible to create a session once the response has been committed.].
 
 If you're wondering how the `AuthenticationManager` is implemented in a real world example, we'll look at that in the <<core-services-authentication-manager,core services chapter>>.
 

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

@@ -133,7 +133,7 @@ With the default configuration, this is typically a comma-separated list of role
 The prefix "ROLE_" is a marker which indicates that a simple comparison with the user's authorities should be made.
 In other words, a normal role-based check should be used.
 Access-control in Spring Security is not limited to the use of simple roles (hence the use of the prefix to differentiate between different types of security attributes).
-We'll see later how the interpretation can vary footnote:[The interpretation of the comma-separated values in the `access` attribute depends on the implementation of the pass:specialcharacters,macros[<<ns-access-manager,AccessDecisionManager>>] which is used.
+We'll see later how the interpretation can vary footnote:[The interpretation of the comma-separated values in the `access` attribute depends on the implementation of the pass:specialcharacters,macros[<<ns-access-manager,AccessDecisionManager>>] which is used.].
 In Spring Security 3.0, the attribute can also be populated with an pass:specialcharacters,macros[<<el-access,EL expression>>].