This will be another entry in the file of things that took me time and frustration to troubleshoot, so here is the recipe, for humankind's benefit. A website that I manage, hosted at a shared hosting plan, displays as if there are no stylesheets. And here's one more ominous warning before the fold: the dreaded error 409.
You know the look of raw HTML, right? Black text on white background, text flowing naturally in the order of appearance on the page, no layout, no backgrounds, image placeholders here and there, etc. Obviously, the stylesheet(s) are not loading. Examining the Network tab in Chrome dev tools reveals that a bunch of requests for stylesheets and SVG images fail with an HTTP error code 409 (Conflict).
Running some of those requests for CSS in a standalone HTTP client reveals that they yield an HTML response along with HTTP code 409, and the response goes like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<script type="text/javascript">
document.cookie = "humans_21909=1"; document.location.reload(true)
</script>
<title>
</title>
</head>
<body>
</body>
</html>
So the server (more likely, Apache's mod_security) wants to see the cookie named humans_21909 with the value of 1. Providing the Cookie: humans_21909=1 header in the standalone HTTP client made the server emit the expected content - the stylesheet. Bingo, but not quite.
The ability to load the stylesheet per se is impressive, but doesn't bring me closer to having the site behave. Dev tools would let me manipulate site cookies, I thought, so let's hand-insert humans_21909 and things would work, hopefully.
Surprisingly, the humans_21909 cookie was already present for the site, but under the path of the site root page. And the path to the failing stylesheet was at a path that was a sibling of the site root, not underneath it. In other words, the site home was something like https://mysite.org/foo/bar/ , and the failing stylesheet was at https://mysite.org/foo/stylesheets/baz.css. The cookie from /foo/bar would not apply to the stylesheet.
And with knowledge, finally, the fix. In Chrome Dev tools, under Application/Cookies, find humans_21909, right click, "Edit path", and change the path to /.
It looks like the humans cookie logic in mod_security is not pervasive - it only kicks in when the URL contains words that mod_security considers sensitive. In my case, the URL contained the word "administrator". Merely navigating to the root of the same site does not emit the humans cookie. I guess the idea was that bot protection only applies to URLs where high value targets might be.
Some of the behaviors that I've seen here are questionable.
- mod_security emits humans_21909 with path set to the current resource's path, instead of site root
- mod_security emits HTML with JavaScript for requests that are not prepared to execute it
On a side note, I've discovered a piece of interesting behavior by Chrome, too. When there are multiple cookies with the same name and same value but different paths, when composing a Cookie header for a request, Chrome places the same name=value entry several times.
Apparently, I'm not only one struggling with 409. Some links:
- https://stackoverflow.com/questions/6785036/reasons-for-a-409-conflict-http-error-when-uploading-a-file-to-sharepoint-using
- https://xenforo.com/community/threads/getting-oops-we-ran-into-some-problems-with-a-409-error.197536/
- https://stackoverflow.com/questions/55915264/scriptdocument-cookie-humans-21909-1-document-location-reloadtrue-scri
- https://www.siteground.com/kb/409-conflict-error/
No comments:
Post a Comment