Answers.Body: <p>A user on their local machine/intranet has a wildcard value setup to resolve to the servers IP address. Even though the DNS is configured to disregard any wildcard value, it seems as though a wildcard value is setup the point to the servers IP on a local/intranet machine.</p>
  
  <p>What was happening was users mistyping the URL. With a typing of the URL "www", the page was still resolving and becoming cached in Craft.</p>
  
  <p>From my local machine, I edited my host file to test this theory and it turned out to be the case.</p>
  
  <p>Found that my rewrite conditions in the htaccess were messed. I've updated my htaccess rules as well (Arcustech server). Forces "WWW" over SSL.</p>
  
  <pre>
  RewriteEngine On
  
      # If SSL request WITHOUT WWW
      RewriteCond %{ENV:SECURE_REDIRECT} on
      RewriteCond %{HTTP_HOST} !^www\..+$ [NC]
      RewriteCond %{HTTP_HOST} !^(local\..+|staging\..+|.+dev)$ [NC]
      RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
  
      # If NOT SSL request WITHOUT WWW
      RewriteCond %{ENV:SECURE_REDIRECT} !=on
      RewriteCond %{HTTP_HOST} !^www\..+$ [NC]
      RewriteCond %{HTTP_HOST} !^(local\..+|staging\..+|.+dev)$ [NC]
      RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
  
      # If NOT SSL request WITH WWW
      RewriteCond %{ENV:SECURE_REDIRECT} !=on
      RewriteCond %{HTTP_HOST} ^www\..+$ [NC]
      RewriteCond %{HTTP_HOST} !^(local\..+|staging\..+|.+dev)$ [NC]
      RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
  
      # Send would-be 404 requests to Craft
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteCond %{REQUEST_URI} !^/(favicon\.ico|apple-touch-icon.*\.png)$ [NC]
      RewriteRule (.+) index.php?p=$1 [QSA,L]
  </pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-11T19:53:10.733Z
Answers.LastActivityDate: 2016-02-11T19:53:10.733Z
Answers.UserDisplayName: Bransin
Body: <p>Craft Pro 2.4.2702</p>
  
  <p>Experiencing an intermittent issue with a Craft site that randomly crops up. It always seems to occur randomly with the caching and the "www" prefix and URLs being cached.</p>
  
  <p>In a Redactor WYSIWYG field, this is the markup.
  <code>
  &lt;a href="https://www.mysite.org/privacy-policy#entry:585:url"&gt;Privacy Policy&lt;/a&gt;
  </code></p>
  
  <p>Randomly at times the page, the page URL links will be cached like so. Notice the <strong>eww</strong>.mysite.org. I've seen other instances where it's been <strong>ww</strong>.mysite.org/page-url, <strong>eee</strong>.mysite.org/page-url, <strong>htp</strong>.mysite.org, <strong>wee</strong>.mysite.org for all URLs that are being cached in the craft_templatecaches table. The urls are generated by <code>entry.getUrl()</code>, but also are manually typed in using a WYSIWYG field.</p>
  
  <p>With my previous example, this is how it's being cached in the database
  <code>&lt;a href="https://eww.mysite.org/privacy-policy"&gt;Privacy Policy&lt;/a&gt;</code></p>
  
  <p>Majority of the caching on the site is done like so.
  <code>
  {%- cache globally unless craft.config.devMode -%}
  ...
  {%- endcache -%}
  </code></p>
  
  <p>At first I thought this might have been the wildcard in the DNS (*.mysite.org) and the page was still resolving with any prefix value and the URLs were being cached like so. I since then have removed the wildcard from the DNS, the page no longer resolves with an incorrect prefix, and this issue seems to pop up randomly.</p>
  
  <p>In my general.php config.</p>
  
  <pre>
  define('URI_SCHEME',  ( isset($_SERVER['HTTPS'] ) ) ? "https://" : "http://" );
  
  define('SITE_URL',    URI_SCHEME . 'www.' . $_SERVER['SERVER_NAME'] . '/');
  </pre>
  
  <p>Htaccess file.</p>
  
  <pre>
  # ----------------------------------------------------------------------
  # Rewrite Craft URLs to remove index.php
  # ----------------------------------------------------------------------
  
      RewriteEngine On
  
      # ----------------------------------------------------------------------
      # Force "www." to beginning of URLs
      # http://stackoverflow.com/questions/4916222/htaccess-how-to-force-www-in-a-generic-way
      # ----------------------------------------------------------------------
      
          RewriteCond %{HTTP_HOST} !^www\. [NC]
          RewriteCond %{HTTP_HOST} ^mysite.org [NC]
          RewriteCond %{HTTPS}s ^on(s)|
          RewriteRule ^ http%1://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
      
  
      # Send would-be 404 requests to Craft
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteCond %{REQUEST_URI} !^/(favicon\.ico|apple-touch-icon.*\.png)$ [NC]
      RewriteRule (.+) index.php?p=$1 [QSA,L]
  
  
  </pre>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-11T01:04:03.570Z
Comments.Text: That's really weird. Are they being saved incorrectly in the template cache table in the database?  Any chance the ones that are messing up have multi-byte characters (Chinese, Japanese, Arabic, etc) in the URL?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-11T17:31:42.607Z
Comments.Text: @BradBell No multi-byte characters in the URLs. They are being saved incorrectly in the template cache table in the DB. This only happens with URLs. A redactor field with an absolute URL of https://www.mysite.org/url#entry:585:url is saved in the template cache table in the db as https://wwe.mysite.org/url and a few other variations. I do have a theory that these are typos of a user typing in the incorrect URL ("w" and "e" being close on the keyboard) and somehow the site is still resolving on their end. I questioned whether it was a user error causing the caching within their intranet
Comments.UserDisplayName: Bransin
Tags: <cache>
Title: Strange cached url prefix with caching
ThreadText: # Strange cached url prefix with caching
  
  (Asked by: username_0 on 2016-02-10)
  
  Craft Pro 2.4.2702
  
  Experiencing an intermittent issue with a Craft site that randomly crops up. It always seems to occur randomly with the caching and the "www" prefix and URLs being cached.
  
  In a Redactor WYSIWYG field, this is the markup.
  `<a href="https://www.mysite.org/privacy-policy#entry:585:url">Privacy Policy</a>`
  
  Randomly at times the page, the page URL links will be cached like so. Notice the **eww**.mysite.org. I've seen other instances where it's been **ww**.mysite.org/page-url, **eee**.mysite.org/page-url, **htp**.mysite.org, **wee**.mysite.org for all URLs that are being cached in the craft\_templatecaches table. The urls are generated by `entry.getUrl()`, but also are manually typed in using a WYSIWYG field.
  
  With my previous example, this is how it's being cached in the database
  `<a href="https://eww.mysite.org/privacy-policy">Privacy Policy</a>`
  
  Majority of the caching on the site is done like so.
  `{%- cache globally unless craft.config.devMode -%}
  ...
  {%- endcache -%}`
  
  At first I thought this might have been the wildcard in the DNS (\*.mysite.org) and the page was still resolving with any prefix value and the URLs were being cached like so. I since then have removed the wildcard from the DNS, the page no longer resolves with an incorrect prefix, and this issue seems to pop up randomly.
  
  In my general.php config.
  
  ```
  
  define('URI_SCHEME',  ( isset($_SERVER['HTTPS'] ) ) ? "https://" : "http://" );
  
  define('SITE_URL',    URI_SCHEME . 'www.' . $_SERVER['SERVER_NAME'] . '/');
  
  ```
  
  Htaccess file.
  
  ```
  
  # ----------------------------------------------------------------------
  # Rewrite Craft URLs to remove index.php
  # ----------------------------------------------------------------------
  
      RewriteEngine On
  
      # ----------------------------------------------------------------------
      # Force "www." to beginning of URLs
      # http://stackoverflow.com/questions/4916222/htaccess-how-to-force-www-in-a-generic-way
      # ----------------------------------------------------------------------
      
          RewriteCond %{HTTP_HOST} !^www\. [NC]
          RewriteCond %{HTTP_HOST} ^mysite.org [NC]
          RewriteCond %{HTTPS}s ^on(s)|
          RewriteRule ^ http%1://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
      
  
      # Send would-be 404 requests to Craft
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteCond %{REQUEST_URI} !^/(favicon\.ico|apple-touch-icon.*\.png)$ [NC]
      RewriteRule (.+) index.php?p=$1 [QSA,L]
  
  ```
  
  **Tags:** cache
  
  > **Comments:**
  > **username_1**: That's really weird. Are they being saved incorrectly in the template cache table in the database?  Any chance the ones that are messing up have multi-byte characters (Chinese, Japanese, Arabic, etc) in the URL?  
  > **username_0**: @username_1 No multi-byte characters in the URLs. They are being saved incorrectly in the template cache table in the DB. This only happens with URLs. A redactor field with an absolute URL of https://www.mysite.org/url#entry:585:url is saved in the template cache table in the db as https://wwe.mysite.org/url and a few other variations. I do have a theory that these are typos of a user typing in the incorrect URL ("w" and "e" being close on the keyboard) and somehow the site is still resolving on their end. I questioned whether it was a user error causing the caching within their intranet  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2016-02-11. Score: 1
  
  A user on their local machine/intranet has a wildcard value setup to resolve to the servers IP address. Even though the DNS is configured to disregard any wildcard value, it seems as though a wildcard value is setup the point to the servers IP on a local/intranet machine.
  
  What was happening was users mistyping the URL. With a typing of the URL "www", the page was still resolving and becoming cached in Craft.
  
  From my local machine, I edited my host file to test this theory and it turned out to be the case.
  
  Found that my rewrite conditions in the htaccess were messed. I've updated my htaccess rules as well (Arcustech server). Forces "WWW" over SSL.
  
  ```
  
  RewriteEngine On
  
      # If SSL request WITHOUT WWW
      RewriteCond %{ENV:SECURE_REDIRECT} on
      RewriteCond %{HTTP_HOST} !^www\..+$ [NC]
      RewriteCond %{HTTP_HOST} !^(local\..+|staging\..+|.+dev)$ [NC]
      RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
  
      # If NOT SSL request WITHOUT WWW
      RewriteCond %{ENV:SECURE_REDIRECT} !=on
      RewriteCond %{HTTP_HOST} !^www\..+$ [NC]
      RewriteCond %{HTTP_HOST} !^(local\..+|staging\..+|.+dev)$ [NC]
      RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
  
      # If NOT SSL request WITH WWW
      RewriteCond %{ENV:SECURE_REDIRECT} !=on
      RewriteCond %{HTTP_HOST} ^www\..+$ [NC]
      RewriteCond %{HTTP_HOST} !^(local\..+|staging\..+|.+dev)$ [NC]
      RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
  
      # Send would-be 404 requests to Craft
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteCond %{REQUEST_URI} !^/(favicon\.ico|apple-touch-icon.*\.png)$ [NC]
      RewriteRule (.+) index.php?p=$1 [QSA,L]
  
  ```
  
  
  ---
  
  