From 0bf0570505e41be266beaa1ccd0266aaed0c3cfb Mon Sep 17 00:00:00 2001
From: Igor Minar
Date: Thu, 8 Aug 2013 10:22:32 -0700
Subject: docs(minErr): rename sce/isecrurl to sce/insecurl

---
 docs/content/error/insecurl.ngdoc     | 30 ++++++++++++++++++++++++++++++
 docs/content/error/sce/isecrurl.ngdoc | 30 ------------------------------
 2 files changed, 30 insertions(+), 30 deletions(-)
 create mode 100644 docs/content/error/insecurl.ngdoc
 delete mode 100644 docs/content/error/sce/isecrurl.ngdoc

(limited to 'docs/content/error')

diff --git a/docs/content/error/insecurl.ngdoc b/docs/content/error/insecurl.ngdoc
new file mode 100644
index 00000000..a4ba5d92
--- /dev/null
+++ b/docs/content/error/insecurl.ngdoc
@@ -0,0 +1,30 @@
+@ngdoc error
+@name $sce:insecurl
+@fullName Blocked loading an untrusted resource
+@description
+
+AngularJS' {@link api/ng.$sce#strictcontextualescaping Strict Contextual Escaping
+(SCE)} mode (enabled by default) has blocked loading a resource from an insecure URL.
+
+Typically, this would occur if you're attempting to load an Angular template from a different
+domain.  It's also possible that a custom directive threw this error for a similar reason.
+
+Angular only loads templates from trusted URLs (by calling {@link api/ng.$sce#getTrustedResourceUrl
+$sce.getTrustedResourceUrl} on the template URL.).
+
+By default, only URLs to the same domain with the same protocol as the application document are
+considered to be trusted.
+
+The {@link api/ng.directive:ngInclude ng-include} directive and {@link guide/directive directives}
+that specify a `templateUrl` require a trusted resource URL.
+
+To load templates from other domains and/or protocols, either adjust the {@link
+api/ng.$sceDelegateProvider#resourceUrlWhitelist whitelist}/ {@link
+api/ng.$sceDelegateProvider#resourceUrlBlacklist blacklist} or wrap the URL with a call to {@link
+api/ng.$sce#trustAsResourceUrl $sce.trustAsResourceUrl}.
+
+**Note**: The browser's {@link
+https://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_XMLHttpRequest Same Origin
+Policy} and {@link http://www.w3.org/TR/cors/ Cross-Origin Resource Sharing (CORS)} policy apply
+that may further restrict whether the template is successfully loaded.  (e.g.  neither cross-domain
+requests won't work on all browsers nor `file://` requests on some browsers)
diff --git a/docs/content/error/sce/isecrurl.ngdoc b/docs/content/error/sce/isecrurl.ngdoc
deleted file mode 100644
index c5a5445d..00000000
--- a/docs/content/error/sce/isecrurl.ngdoc
+++ /dev/null
@@ -1,30 +0,0 @@
-@ngdoc error
-@name $sce:isecrurl
-@fullName Blocked loading an untrusted resource
-@description
-
-AngularJS' {@link api/ng.$sce#strictcontextualescaping Strict Contextual Escaping
-(SCE)} mode (enabled by default) has blocked loading a resource from an insecure URL.
-
-Typically, this would occur if you're attempting to load an Angular template from a different
-domain.  It's also possible that a custom directive threw this error for a similar reason.
-
-Angular only loads templates from trusted URLs (by calling {@link api/ng.$sce#getTrustedResourceUrl
-$sce.getTrustedResourceUrl} on the template URL.).
-
-By default, only URLs to the same domain with the same protocol as the application document are
-considered to be trusted.
-
-The {@link api/ng.directive:ngInclude ng-include} directive and {@link guide/directive directives}
-that specify a `templateUrl` require a trusted resource URL.
-
-To load templates from other domains and/or protocols, either adjust the {@link
-api/ng.$sceDelegateProvider#resourceUrlWhitelist whitelist}/ {@link
-api/ng.$sceDelegateProvider#resourceUrlBlacklist blacklist} or wrap the URL with a call to {@link
-api/ng.$sce#trustAsResourceUrl $sce.trustAsResourceUrl}.
-
-**Note**: The browser's {@link
-https://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_XMLHttpRequest Same Origin
-Policy} and {@link http://www.w3.org/TR/cors/ Cross-Origin Resource Sharing (CORS)} policy apply
-that may further restrict whether the template is successfully loaded.  (e.g.  neither cross-domain
-requests won't work on all browsers nor `file://` requests on some browsers)
-- 
cgit v1.2.3