Source code
import re
from urllib.parse import urlsplit
from django.conf import settings
from django.core.exceptions import PermissionDenied
from django.core.mail import MailerDoesNotExist, mail_managers, mailers
from django.http import HttpResponsePermanentRedirect
from django.middleware import MiddlewareMixin
from django.urls import is_valid_path
from django.utils.http import escape_leading_slashes
class CommonMiddleware(MiddlewareMixin):
response_redirect_class = HttpResponsePermanentRedirect
def process_request(self, request):
user_agent = request.META.get("HTTP_USER_AGENT")
if user_agent is not None:
for user_agent_regex in settings.DISALLOWED_USER_AGENTS:
if user_agent_regex.search(user_agent):
raise PermissionDenied("Forbidden user agent")
host = request.get_host()
if settings.PREPEND_WWW and host and not host.startswith("www."):
if self.should_redirect_with_slash(request):
path = self.get_full_path_with_slash(request)
else:
path = request.get_full_path()
return self.response_redirect_class(f"{request.scheme}://www.{host}{path}")
def should_redirect_with_slash(self, request):
if settings.APPEND_SLASH and not request.path_info.endswith("/"):
urlconf = getattr(request, "urlconf", None)
if not is_valid_path(request.path_info, urlconf):
match = is_valid_path("%s/" % request.path_info, urlconf)
if match:
view = match.func
return getattr(view, "should_append_slash", True)
return False
def get_full_path_with_slash(self, request):
new_path = request.get_full_path(force_append_slash=True)
new_path = escape_leading_slashes(new_path)
if settings.DEBUG and request.method in ("DELETE", "POST", "PUT", "PATCH"):
raise RuntimeError(
"You called this URL via %(method)s, but the URL doesn't end "
"in a slash and you have APPEND_SLASH set. Django can't "
"redirect to the slash URL while maintaining %(method)s data. "
"Change your form to point to %(url)s (note the trailing "
"slash), or set APPEND_SLASH=False in your Django settings."
% {
"method": request.method,
"url": request.get_host() + new_path,
}
)
return new_path
def process_response(self, request, response):
if response.status_code == 404 and self.should_redirect_with_slash(request):
response = self.response_redirect_class(
self.get_full_path_with_slash(request)
)
if not response.streaming and not response.has_header("Content-Length"):
response.headers["Content-Length"] = str(len(response.content))
return response
Run 1
The code is well-structured with clear method separation and follows Django conventions. Most methods are flat with minimal nesting, and each line generally performs one logical action. Naming is descriptive, making the intent reasonably clear. However, there are areas for improvement: the docstrings are empty placeholders, some logic (e.g., the `should_redirect_with_slash` method) has multiple nested conditionals, and a few comments appear as unexplained placeholders. The code length is appropriate, but the readability is slightly reduced by incomplete documentation and the complexity of the redirect logic. Overall, it demonstrates good structure and flow, but would benefit from clearer inline explanations and formal docstrings.
Run 2
The code is well-structured into clear methods with distinct responsibilities (request filtering, redirect logic, response processing). Nesting is moderate, with only 2-3 levels in conditionals. Intent is clear through descriptive method names like should_redirect_with_slash and get_full_path_with_slash, and comments explain Django-specific behavior. Code length is appropriate—not overly verbose despite some repetitive urlconf handling. Action granularity is good, with one primary operation per line and minimal chained calls. Reading flow is logical: request validation → host/redirect checks → response post-processing. Minor deductions: unused imports (re, urlsplit, mail_managers, mailers) add clutter, and inline comments are occasionally sparse, making the rationale for certain Django conventions less obvious to newcomers. Overall highly readable.
Run 3
The code is generally well-structured and readable. It has clear class and method separation, uses descriptive method names, and maintains a logical flow from request processing to response handling. Nesting is mostly flat, with only two levels inside loops. However, readability is reduced by excessive blank lines and placeholder comments, which create visual gaps without adding meaning. Some methods mix multiple actions, such as checking DEBUG and raising RuntimeError within path construction, reducing action granularity. The intent is mostly clear, especially in should_redirect_with_slash, but the use of multiple conditional checks within a single line in process_request slightly reduces clarity. Code length is reasonable, but certain sections feel unnecessarily spread out. Overall, it is readable but could benefit from tighter formatting and more explicit comments explaining the reasoning behind non-obvious logic.
Run 1
Code Structure: Responsibilities are logically separated into request handling, redirect helpers, and response handling. Nesting: Most code is shallow, but user-agent filtering and slash validation contain several nested conditions. Clarity of intent: Descriptive method names and explicit settings checks communicate purpose well; missing docstrings leave some middleware-specific behavior unexplained. Code length: Generally concise, though excessive blank lines and several unused imports add clutter. Action granularity: Statements mostly perform one action per line, with readable formatting for the lengthy exception message. Reading flow: Methods follow a coherent request-to-response progression, and helper calls simplify the main logic, but whitespace gaps interrupt visual continuity.
Run 2
Code Structure: Well organized into focused middleware hooks and helper methods, separating request filtering, redirects, and response updates. Nesting: Mostly manageable, but user-agent checks and slash validation reach three conditional or loop levels. Clarity of intent: Descriptive method names, settings, and variables communicate purpose; missing documentation leaves subtle redirect behavior less explicit. Code length: Generally concise, though excessive blank lines and unused imports add clutter; the lengthy error message is useful rather than unnecessary. Action granularity: Statements generally perform one action per line, with appropriately formatted multiline expressions. Reading flow: Request handling, redirect helpers, and response handling form a natural sequence, but irregular whitespace interrupts scanning.
Run 3
Code Structure: Responsibilities are logically separated into request handling, slash-redirect checks, path construction, and response handling. Nesting: Mostly moderate, but user-agent filtering and slash validation reach three conditional or loop levels. Clarity of intent: Descriptive method names and explicit conditions communicate purpose well, although missing documentation leaves some redirect subtleties unexplained. Code length: Functional code is reasonably concise, but excessive blank lines and unused imports introduce clutter; the long exception message is informative rather than gratuitous. Action granularity: Statements generally perform one action per line, with readable formatting for longer expressions. Reading flow: Methods follow a coherent request-to-response progression, but irregular whitespace disrupts scanning slightly.