Morph MORPH
SIGN IN SIGN UP
angular / angular.js UNCLAIMED

AngularJS - HTML enhanced for web apps!

0 0 0 JavaScript
Normal View History Raw
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
'use strict';
feat($http): support handling additional XHR events Closes #14367 Closes #11547 Closes #1934
2016-04-04 13:48:43 +01:00
/* global MockXhr: false */
fix($http): set correct xhrStatus in response when using 'timeout' This correctly sets "timeout" if a request fails because the timeout (numerical or $timeout) is exceeded, and "abort" if the request is aborted by resolving a promise that was passed in.
2017-10-08 21:48:06 +02:00
// The http specs run against the mocked httpBackend
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
describe('$http', function() {
refactor($browser): split cookie access into $$cookieReader and $$cookieWriter services
2015-03-02 13:24:30 +02:00
var callback, mockedCookies;
feat($http): support custom params serializers Closes #3740 Closes #7429 Closes #9224 Closes #11461
2015-03-30 15:37:04 +02:00
var customParamSerializer = function(params) {
return Object.keys(params).join('_');
};
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
feat($http): support sending XSRF token to whitelisted origins Normally, the XSRF token will not be set for cross-origin requests. With this commit, it is possible to whitelist additional origins, so that requests to these origins will include the XSRF token header. Fixes #7862
2016-07-10 00:23:18 +03:00
beforeEach(module(function($exceptionHandlerProvider) {
$exceptionHandlerProvider.mode('log');
refactor(module): strict separation between module-config / app-runtime
2012-01-12 11:06:10 -08:00
callback = jasmine.createSpy('done');
refactor($browser): split cookie access into $$cookieReader and $$cookieWriter services
2015-03-02 13:24:30 +02:00
mockedCookies = {};
feat($http): support sending XSRF token to whitelisted origins Normally, the XSRF token will not be set for cross-origin requests. With this commit, it is possible to whitelist additional origins, so that requests to these origins will include the XSRF token header. Fixes #7862
2016-07-10 00:23:18 +03:00
}));
feat($http): add withCredentials config option
2012-04-03 11:00:52 -07:00
feat($http): support custom params serializers Closes #3740 Closes #7429 Closes #9224 Closes #11461
2015-03-30 15:37:04 +02:00
beforeEach(module({
feat($http): support sending XSRF token to whitelisted origins Normally, the XSRF token will not be set for cross-origin requests. With this commit, it is possible to whitelist additional origins, so that requests to these origins will include the XSRF token header. Fixes #7862
2016-07-10 00:23:18 +03:00
$$cookieReader: function() { return mockedCookies; },
feat($http): support custom params serializers Closes #3740 Closes #7429 Closes #9224 Closes #11461
2015-03-30 15:37:04 +02:00
customParamSerializer: customParamSerializer
}));
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
afterEach(inject(function($exceptionHandler, $httpBackend, $rootScope) {
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
forEach($exceptionHandler.errors, function(e) {
chore(jshint): enforce jshint for tests Closes #7264
2014-04-26 23:07:28 +03:00
dump('Unhandled exception: ', e);
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
});
if ($exceptionHandler.errors.length) {
throw 'Unhandled exceptions trapped in $exceptionHandler!';
}
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat(mock.$httpBackend): add verifyNoOutstandingRequest method + rename verifyExpectations to verifyNoOutstandingExpectation
2011-10-31 20:34:03 -07:00
$httpBackend.verifyNoOutstandingExpectation();
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
}));
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): add response interceptors
2011-11-30 03:58:34 -05:00
describe('$httpProvider', function() {
describe('interceptors', function() {
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
it('should chain request, requestReject, response and responseReject interceptors', function() {
module(function($httpProvider) {
var savedConfig, savedResponse;
$httpProvider.interceptors.push(function($q) {
return {
request: function(config) {
config.url += '/1';
savedConfig = config;
return $q.reject('/2');
}
};
});
$httpProvider.interceptors.push(function($q) {
return {
requestError: function(error) {
savedConfig.url += error;
refactor($q): replace occurrences of `.when()` with `.resolve()` Related to #13709. Closes #15442
2016-11-27 00:00:10 -08:00
return $q.resolve(savedConfig);
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
}
};
});
$httpProvider.interceptors.push(function() {
return {
responseError: function(rejection) {
savedResponse.data += rejection;
return savedResponse;
}
};
});
$httpProvider.interceptors.push(function($q) {
return {
response: function(response) {
response.data += ':1';
chore(jshint): enforce jshint for tests Closes #7264
2014-04-26 23:07:28 +03:00
savedResponse = response;
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
return $q.reject(':2');
}
};
});
});
inject(function($http, $httpBackend, $rootScope) {
var response;
$httpBackend.expect('GET', '/url/1/2').respond('response');
$http({method: 'GET', url: '/url'}).then(function(r) {
response = r;
});
$rootScope.$apply();
$httpBackend.flush();
expect(response.data).toEqual('response:1:2');
});
});
it('should verify order of execution', function() {
module(function($httpProvider) {
$httpProvider.interceptors.push(function($q) {
return {
request: function(config) {
config.url += '/outer';
return config;
},
response: function(response) {
response.data = '{' + response.data + '} outer';
return response;
}
};
});
$httpProvider.interceptors.push(function($q) {
return {
request: function(config) {
config.url += '/inner';
return config;
},
response: function(response) {
response.data = '{' + response.data + '} inner';
return response;
}
};
});
});
inject(function($http, $httpBackend) {
var response;
$httpBackend.expect('GET', '/url/outer/inner').respond('response');
$http({method: 'GET', url: '/url'}).then(function(r) {
response = r;
});
$httpBackend.flush();
chore($http): remove deprecated responseInterceptors functionality Code cleanup! response interceptors have been deprecated for some time, and it is confusing to have two APIs, one of which is slightly "hidden" and hard to see, which perform the same task. The newer API is a bit cleaner and more visible, so this is naturally preferred. BREAKING CHANGE: Previously, it was possible to register a response interceptor like so: // register the interceptor as a service $provide.factory('myHttpInterceptor', function($q, dependency1, dependency2) { return function(promise) { return promise.then(function(response) { // do something on success return response; }, function(response) { // do something on error if (canRecover(response)) { return responseOrNewPromise } return $q.reject(response); }); } }); $httpProvider.responseInterceptors.push('myHttpInterceptor'); Now, one must use the newer API introduced in v1.1.4 (4ae46814), like so: $provide.factory('myHttpInterceptor', function($q) { return { response: function(response) { // do something on success return response; }, responseError: function(response) { // do something on error if (canRecover(response)) { return responseOrNewPromise } return $q.reject(response); } }; }); $httpProvider.interceptors.push('myHttpInterceptor'); More details on the new interceptors API (which has been around as of v1.1.4) can be found at https://docs.angularjs.org/api/ng/service/$http#interceptors Closes #7266 Closes #7267
2014-04-26 22:22:16 -04:00
expect(response.data).toEqual('{{response} inner} outer');
refactor(module): strict separation between module-config / app-runtime
2012-01-12 11:06:10 -08:00
});
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
describe('request interceptors', function() {
it('should pass request config as a promise', function() {
var run = false;
module(function($httpProvider) {
$httpProvider.interceptors.push(function() {
return {
request: function(config) {
expect(config.url).toEqual('/url');
chore(eslint): enable `quotes: ["error", "single"]` The quotes rule had to be disabled for e2e tests generated from ngdoc because dgeni templates use double quotes as string delimiters. Since we can't have guarantees that dgeni template wrappers will follow the same JS code style the Angular 1 repo uses, we should find a way to enforce our ESLint setup only for the parts in this repo, perhaps via prepending a generated `/* eslint-enable OUR_RULES */` pragma. Closes #15011
2016-08-10 12:13:14 +02:00
expect(config.data).toEqual({one: 'two'});
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
expect(config.headers.foo).toEqual('bar');
run = true;
return config;
}
};
});
});
inject(function($http, $httpBackend, $rootScope) {
$httpBackend.expect('POST', '/url').respond('');
$http({method: 'POST', url: '/url', data: {one: 'two'}, headers: {foo: 'bar'}});
$rootScope.$apply();
expect(run).toEqual(true);
});
});
it('should allow manipulation of request', function() {
module(function($httpProvider) {
$httpProvider.interceptors.push(function() {
return {
request: function(config) {
config.url = '/intercepted';
config.headers.foo = 'intercepted';
return config;
}
};
});
});
inject(function($http, $httpBackend, $rootScope) {
style(*): add rule disallowSpacesInAnonymousFunctionExpression beforeOpeningRoundBrace, including i18n generator
2014-10-22 17:31:27 -04:00
$httpBackend.expect('GET', '/intercepted', null, function(headers) {
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
return headers.foo === 'intercepted';
}).respond('');
$http.get('/url');
$rootScope.$apply();
});
});
fix($http): allow interceptors to completely override headers Closes #2770
2013-07-12 17:42:37 -07:00
it('should allow replacement of the headers object', function() {
module(function($httpProvider) {
$httpProvider.interceptors.push(function() {
return {
request: function(config) {
config.headers = {foo: 'intercepted'};
return config;
}
};
});
});
inject(function($http, $httpBackend, $rootScope) {
style(*): add rule disallowSpacesInAnonymousFunctionExpression beforeOpeningRoundBrace, including i18n generator
2014-10-22 17:31:27 -04:00
$httpBackend.expect('GET', '/url', null, function(headers) {
fix($http): allow interceptors to completely override headers Closes #2770
2013-07-12 17:42:37 -07:00
return angular.equals(headers, {foo: 'intercepted'});
}).respond('');
$http.get('/url');
$rootScope.$apply();
});
});
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
it('should reject the http promise if an interceptor fails', function() {
var reason = new Error('interceptor failed');
module(function($httpProvider) {
$httpProvider.interceptors.push(function($q) {
return {
request: function(promise) {
return $q.reject(reason);
}
};
});
});
inject(function($http, $httpBackend, $rootScope) {
var success = jasmine.createSpy(), error = jasmine.createSpy();
$http.get('/url').then(success, error);
$rootScope.$apply();
expect(success).not.toHaveBeenCalled();
expect(error).toHaveBeenCalledWith(reason);
});
});
it('should not manipulate the passed-in config', function() {
module(function($httpProvider) {
$httpProvider.interceptors.push(function() {
return {
request: function(config) {
config.url = '/intercepted';
config.headers.foo = 'intercepted';
return config;
}
};
});
});
inject(function($http, $httpBackend, $rootScope) {
fix($http): do not modify the config object passed into $http short methods Update $http's createShortMethods and createShortMethodsWithData to extend an empty object instead of the passed-in config. Previously, since $http was extending the passed-in config, the changes to the config object persisted even after the call to $http's get/post/etc. returned. This causes unexpected behavior if that config object is reused in subsequent calls to $http. The existing test in httpSpec was not properly testing this situation. Closes: #11764
2015-04-29 21:28:26 -05:00
var config = { headers: { foo: 'bar'} };
var configCopy = angular.copy(config);
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
$httpBackend.expect('GET', '/intercepted').respond('');
fix($http): do not modify the config object passed into $http short methods Update $http's createShortMethods and createShortMethodsWithData to extend an empty object instead of the passed-in config. Previously, since $http was extending the passed-in config, the changes to the config object persisted even after the call to $http's get/post/etc. returned. This causes unexpected behavior if that config object is reused in subsequent calls to $http. The existing test in httpSpec was not properly testing this situation. Closes: #11764
2015-04-29 21:28:26 -05:00
$http.get('/url', config);
$rootScope.$apply();
expect(config).toEqual(configCopy);
$httpBackend.expect('POST', '/intercepted').respond('');
$http.post('/url', {bar: 'baz'}, config);
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
$rootScope.$apply();
fix($http): do not modify the config object passed into $http short methods Update $http's createShortMethods and createShortMethodsWithData to extend an empty object instead of the passed-in config. Previously, since $http was extending the passed-in config, the changes to the config object persisted even after the call to $http's get/post/etc. returned. This causes unexpected behavior if that config object is reused in subsequent calls to $http. The existing test in httpSpec was not properly testing this situation. Closes: #11764
2015-04-29 21:28:26 -05:00
expect(config).toEqual(configCopy);
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
});
});
it('should support interceptors defined as services', function() {
module(function($provide, $httpProvider) {
$provide.factory('myInterceptor', function() {
return {
request: function(config) {
config.url = '/intercepted';
return config;
}
};
});
$httpProvider.interceptors.push('myInterceptor');
});
inject(function($http, $httpBackend, $rootScope) {
$httpBackend.expect('POST', '/intercepted').respond('');
$http.post('/url');
$rootScope.$apply();
});
});
it('should support complex interceptors based on promises', function() {
module(function($provide, $httpProvider) {
$provide.factory('myInterceptor', function($q, $rootScope) {
return {
request: function(config) {
refactor($q): replace occurrences of `.when()` with `.resolve()` Related to #13709. Closes #15442
2016-11-27 00:00:10 -08:00
return $q.resolve('/intercepted').then(function(intercepted) {
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
config.url = intercepted;
return config;
});
}
};
});
$httpProvider.interceptors.push('myInterceptor');
});
inject(function($http, $httpBackend, $rootScope) {
$httpBackend.expect('POST', '/intercepted').respond('');
$http.post('/two');
$rootScope.$apply();
});
});
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
describe('the instance', function() {
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
var $httpBackend, $http, $rootScope, $sce;
refactor(module): strict separation between module-config / app-runtime
2012-01-12 11:06:10 -08:00
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
beforeEach(module(function($sceDelegateProvider) {
// Setup a special whitelisted url that we can use in testing JSONP requests
$sceDelegateProvider.resourceUrlWhitelist(['http://special.whitelisted.resource.com/**']);
}));
beforeEach(inject(['$httpBackend', '$http', '$rootScope', '$sce', function($hb, $h, $rs, $sc) {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend = $hb;
$http = $h;
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
$rootScope = $rs;
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
$sce = $sc;
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
spyOn($rootScope, '$apply').and.callThrough();
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
}]));
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
it('should throw error if the request configuration is not an object', function() {
fix ($http): throw error when string URL is provided
2014-11-22 12:07:19 -08:00
expect(function() {
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
$http('/url');
fix ($http): throw error when string URL is provided
2014-11-22 12:07:19 -08:00
}).toThrowMinErr('$http','badreq', 'Http request configuration must be an object. Received: /url');
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
});
fix ($http): throw error when string URL is provided
2014-11-22 12:07:19 -08:00
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
it('should throw error if the request configuration url is not a string nor a trusted object', function() {
expect(function() {
$http({url: false});
}).toThrowMinErr('$http','badreq', 'Http request configuration url must be a string or a $sce trusted object. Received: false');
expect(function() {
$http({url: null});
}).toThrowMinErr('$http','badreq', 'Http request configuration url must be a string or a $sce trusted object. Received: null');
expect(function() {
$http({url: 42});
}).toThrowMinErr('$http','badreq', 'Http request configuration url must be a string or a $sce trusted object. Received: 42');
fix($http): throw if url passed is not a string Throw to prevent hard to debug errors in functions that are called later. Fixes #12925 Closes #13444
2015-12-03 10:30:48 -06:00
expect(function() {
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
$http({});
}).toThrowMinErr('$http','badreq', 'Http request configuration url must be a string or a $sce trusted object. Received: undefined');
fix($http): throw if url passed is not a string Throw to prevent hard to debug errors in functions that are called later. Fixes #12925 Closes #13444
2015-12-03 10:30:48 -06:00
});
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
it('should accept a $sce trusted object for the request configuration url', function() {
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
$httpBackend.expect('GET', '/url').respond('');
$http({url: $sce.trustAsResourceUrl('/url')});
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
});
fix($http): throw if url passed is not a string Throw to prevent hard to debug errors in functions that are called later. Fixes #12925 Closes #13444
2015-12-03 10:30:48 -06:00
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
it('should send GET requests if no method specified', function() {
fix($http): send GET requests by default Fixes #5985 Closes #6401
2014-02-21 22:24:27 +01:00
$httpBackend.expect('GET', '/url').respond('');
$http({url: '/url'});
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
it('should do basic request', function() {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.expect('GET', '/url').respond('');
$http({url: '/url', method: 'GET'});
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
it('should pass data if specified', function() {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.expect('POST', '/url', 'some-data').respond('');
$http({url: '/url', method: 'POST', data: 'some-data'});
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat(http): added params parameter The params parameter can now be used to serialize parameters in the URLs. The serialization does proper escaping and JSON encoding if it is an object.
2012-03-23 13:41:48 -07:00
describe('params', function() {
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
it('should do basic request with params and encode', function() {
feat(http): added params parameter The params parameter can now be used to serialize parameters in the URLs. The serialization does proper escaping and JSON encoding if it is an object.
2012-03-23 13:41:48 -07:00
$httpBackend.expect('GET', '/url?a%3D=%3F%26&b=2').respond('');
$http({url: '/url', params: {'a=':'?&', b:2}, method: 'GET'});
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
});
feat(http): added params parameter The params parameter can now be used to serialize parameters in the URLs. The serialization does proper escaping and JSON encoding if it is an object.
2012-03-23 13:41:48 -07:00
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
it('should merge params if url contains some already', function() {
feat(http): added params parameter The params parameter can now be used to serialize parameters in the URLs. The serialization does proper escaping and JSON encoding if it is an object.
2012-03-23 13:41:48 -07:00
$httpBackend.expect('GET', '/url?c=3&a=1&b=2').respond('');
$http({url: '/url?c=3', params: {a:1, b:2}, method: 'GET'});
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
});
feat(http): added params parameter The params parameter can now be used to serialize parameters in the URLs. The serialization does proper escaping and JSON encoding if it is an object.
2012-03-23 13:41:48 -07:00
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
it('should jsonify objects in params map', function() {
fix($http): do not encode special characters `@$:,` in params encodeURIComponent is too aggressive and doesn't follow http://www.ietf.org/rfc/rfc3986.txt with regards to the character set (pchar) allowed in path segments so we need this test to make sure that we don't over-encode the params and break stuff like buzz api which uses @self. This is has already been fixed in `$resource`. This commit fixes it in a same way for `$http` as well. BREAKING CHANGE: $http does follow RFC3986 and does not encode special characters like `$@,:` in params. If your application needs to encode these characters, encode them manually, before sending the request.
2013-02-14 14:39:55 -08:00
$httpBackend.expect('GET', '/url?a=1&b=%7B%22c%22:3%7D').respond('');
feat(http): added params parameter The params parameter can now be used to serialize parameters in the URLs. The serialization does proper escaping and JSON encoding if it is an object.
2012-03-23 13:41:48 -07:00
$http({url: '/url', params: {a:1, b:{c:3}}, method: 'GET'});
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
});
fix($http): config.param should expand array values properly Today, calling e.g. $http(url, { params: { a: [1,2,3] } }) results in a query string like "?a=%5B1%2C2%2C3%5D" which is undesirable. This commit enhances buildURL to createa query string like "?a=1&a=2&a=3". BREAKING CHANGE: if the server relied on the buggy behavior then either the backend should be fixed or a simple serialization of the array should be done on the client before calling the $http service. Closes #1363
2012-09-14 17:42:39 -04:00
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
it('should expand arrays in params map', function() {
chore(jshint): enforce jshint for tests Closes #7264
2014-04-26 23:07:28 +03:00
$httpBackend.expect('GET', '/url?a=1&a=2&a=3').respond('');
$http({url: '/url', params: {a: [1,2,3]}, method: 'GET'});
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
});
fix($http): do not encode special characters `@$:,` in params encodeURIComponent is too aggressive and doesn't follow http://www.ietf.org/rfc/rfc3986.txt with regards to the character set (pchar) allowed in path segments so we need this test to make sure that we don't over-encode the params and break stuff like buzz api which uses @self. This is has already been fixed in `$resource`. This commit fixes it in a same way for `$http` as well. BREAKING CHANGE: $http does follow RFC3986 and does not encode special characters like `$@,:` in params. If your application needs to encode these characters, encode them manually, before sending the request.
2013-02-14 14:39:55 -08:00
it('should not encode @ in url params', function() {
docs: fix typos throughout the codebase Closes #13519
2015-12-12 00:26:17 +02:00
//encodeURIComponent is too aggressive and doesn't follow http://www.ietf.org/rfc/rfc3986.txt
fix($http): do not encode special characters `@$:,` in params encodeURIComponent is too aggressive and doesn't follow http://www.ietf.org/rfc/rfc3986.txt with regards to the character set (pchar) allowed in path segments so we need this test to make sure that we don't over-encode the params and break stuff like buzz api which uses @self. This is has already been fixed in `$resource`. This commit fixes it in a same way for `$http` as well. BREAKING CHANGE: $http does follow RFC3986 and does not encode special characters like `$@,:` in params. If your application needs to encode these characters, encode them manually, before sending the request.
2013-02-14 14:39:55 -08:00
//with regards to the character set (pchar) allowed in path segments
//so we need this test to make sure that we don't over-encode the params and break stuff
//like buzz api which uses @self
$httpBackend.expect('GET', '/Path?!do%26h=g%3Da+h&:bar=$baz@1').respond('');
$http({url: '/Path', params: {':bar': '$baz@1', '!do&h': 'g=a h'}, method: 'GET'});
});
fix($http): do not add trailing question Closes #6342
2014-02-19 15:14:14 +04:00
it('should not add question mark when params is empty', function() {
$httpBackend.expect('GET', '/url').respond('');
$http({url: '/url', params: {}, method: 'GET'});
chore(jshint): enforce jshint for tests Closes #7264
2014-04-26 23:07:28 +03:00
});
fix($http): fix double-quoted date issue when encoding params This commit special cases date handling rather than calling toJSON as we always need a string representation of the object. $http was wrapping dates in double quotes leading to query strings like this: ?date=%222014-07-07T23:00:00.000Z%22 Closes #8150 Closes #6128 Closes #8154
2014-07-11 17:34:52 +01:00
it('should not double quote dates', function() {
$httpBackend.expect('GET', '/url?date=2014-07-15T17:30:00.000Z').respond('');
$http({url: '/url', params: {date:new Date('2014-07-15T17:30:00.000Z')}, method: 'GET'});
});
feat($http): support custom params serializers Closes #3740 Closes #7429 Closes #9224 Closes #11461
2015-03-30 15:37:04 +02:00
describe('custom params serialization', function() {
it('should allow specifying custom paramSerializer as function', function() {
$httpBackend.expect('GET', '/url?foo_bar').respond('');
$http({url: '/url', params: {foo: 'fooVal', bar: 'barVal'}, paramSerializer: customParamSerializer});
});
it('should allow specifying custom paramSerializer as function from DI', function() {
$httpBackend.expect('GET', '/url?foo_bar').respond('');
$http({url: '/url', params: {foo: 'fooVal', bar: 'barVal'}, paramSerializer: 'customParamSerializer'});
});
});
feat(http): added params parameter The params parameter can now be used to serialize parameters in the URLs. The serialization does proper escaping and JSON encoding if it is an object.
2012-03-23 13:41:48 -07:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
describe('callbacks', function() {
it('should pass in the response object when a request is successful', function() {
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
$httpBackend.expect('GET', '/url').respond(207, 'my content', {'content-encoding': 'smurf'});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$http({url: '/url', method: 'GET'}).then(function(response) {
expect(response.data).toBe('my content');
expect(response.status).toBe(207);
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
expect(response.headers()).toEqual(extend(Object.create(null), {'content-encoding': 'smurf'}));
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(response.config.url).toBe('/url');
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
callback();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
$httpBackend.flush();
feat($http): add xhr statusText to completeRequest callback Makes xhr status text accessible is $http success/error callback. See www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-statustext Closes #2335 Closes #2665 Closes #6713
2013-07-18 02:08:38 +10:00
expect(callback).toHaveBeenCalledOnce();
});
it('should pass statusText in response object when a request is successful', function() {
$httpBackend.expect('GET', '/url').respond(200, 'SUCCESS', {}, 'OK');
$http({url: '/url', method: 'GET'}).then(function(response) {
expect(response.statusText).toBe('OK');
callback();
});
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
});
it('should pass statusText in response object when a request fails', function() {
$httpBackend.expect('GET', '/url').respond(404, 'ERROR', {}, 'Not Found');
$http({url: '/url', method: 'GET'}).then(null, function(response) {
expect(response.statusText).toBe('Not Found');
callback();
});
$httpBackend.flush();
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
expect(callback).toHaveBeenCalledOnce();
});
feat($http): allow differentiation between XHR completion, error, abort, timeout Previously, it wasn't possible to tell if an `$http`-initiated XMLHttpRequest was completed normally or with an error or it was aborted or timed out. This commit adds a new property on the `response` object (`xhrStatus`) which allows to defferentiate between the possible statuses. Fixes #15924 Closes #15847
2017-02-21 23:42:16 +01:00
it('should pass xhrStatus in response object when a request is successful', function() {
$httpBackend.expect('GET', '/url').respond(200, 'SUCCESS', {}, 'OK');
$http({url: '/url', method: 'GET'}).then(function(response) {
expect(response.xhrStatus).toBe('complete');
callback();
});
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
});
it('should pass xhrStatus in response object when a request fails', function() {
$httpBackend.expect('GET', '/url').respond(404, 'ERROR', {}, 'Not Found');
$http({url: '/url', method: 'GET'}).then(null, function(response) {
expect(response.xhrStatus).toBe('complete');
callback();
});
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
});
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should pass in the response object when a request failed', function() {
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
$httpBackend.expect('GET', '/url').respond(543, 'bad error', {'request-id': '123'});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$http({url: '/url', method: 'GET'}).then(null, function(response) {
expect(response.data).toBe('bad error');
expect(response.status).toBe(543);
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
expect(response.headers()).toEqual(extend(Object.create(null), {'request-id': '123'}));
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(response.config.url).toBe('/url');
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
callback();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
describe('response headers', function() {
it('should return single header', function() {
$httpBackend.expect('GET', '/url').respond('', {'date': 'date-val'});
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
callback.and.callFake(function(r) {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(r.headers('date')).toBe('date-val');
});
$http({url: '/url', method: 'GET'}).then(callback);
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should return null when single header does not exist', function() {
$httpBackend.expect('GET', '/url').respond('', {'Some-Header': 'Fake'});
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
callback.and.callFake(function(r) {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
r.headers(); // we need that to get headers parsed first
expect(r.headers('nothing')).toBe(null);
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
chore(jshint): enforce jshint for tests Closes #7264
2014-04-26 23:07:28 +03:00
$http({url: '/url', method: 'GET'}).then(callback);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
feat($http): add promise support quite messy, some tests are missing, contains an experimental jasmine DI support)
2011-11-24 03:53:04 -08:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should return all headers as object', function() {
$httpBackend.expect('GET', '/url').respond('', {
'content-encoding': 'gzip',
'server': 'Apache'
});
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
callback.and.callFake(function(r) {
expect(r.headers()).toEqual(extend(Object.create(null), {'content-encoding': 'gzip', 'server': 'Apache'}));
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
$http({url: '/url', method: 'GET'}).then(callback);
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should return empty object for jsonp request', function() {
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
callback.and.callFake(function(r) {
expect(r.headers()).toEqual(Object.create(null));
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
$httpBackend.expect('JSONP', '/some?callback=JSON_CALLBACK').respond(200);
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
$http({url: $sce.trustAsResourceUrl('/some'), method: 'JSONP'}).then(callback);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
describe('response headers parser', function() {
chore(jshint): enforce jshint for tests Closes #7264
2014-04-26 23:07:28 +03:00
/* global parseHeaders: false */
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should parse basic', function() {
var parsed = parseHeaders(
'date: Thu, 04 Aug 2011 20:23:08 GMT\n' +
'content-encoding: gzip\n' +
'transfer-encoding: chunked\n' +
'x-cache-info: not cacheable; response has already expired, not cacheable; response has already expired\n' +
'connection: Keep-Alive\n' +
'x-backend-server: pm-dekiwiki03\n' +
'pragma: no-cache\n' +
'server: Apache\n' +
'x-frame-options: DENY\n' +
'content-type: text/html; charset=utf-8\n' +
'vary: Cookie, Accept-Encoding\n' +
'keep-alive: timeout=5, max=1000\n' +
'expires: Thu: , 19 Nov 1981 08:52:00 GMT\n');
expect(parsed['date']).toBe('Thu, 04 Aug 2011 20:23:08 GMT');
expect(parsed['content-encoding']).toBe('gzip');
expect(parsed['transfer-encoding']).toBe('chunked');
expect(parsed['keep-alive']).toBe('timeout=5, max=1000');
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should parse lines without space after colon', function() {
expect(parseHeaders('key:value').key).toBe('value');
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should trim the values', function() {
expect(parseHeaders('key: value ').key).toBe('value');
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should allow headers without value', function() {
expect(parseHeaders('key:').key).toBe('');
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should merge headers with same key', function() {
expect(parseHeaders('key: a\nkey:b\n').key).toBe('a, b');
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should normalize keys to lower case', function() {
expect(parseHeaders('KeY: value').key).toBe('value');
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should parse CRLF as delimiter', function() {
// IE does use CRLF
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
expect(parseHeaders('a: b\r\nc: d\r\n')).toEqual(extend(Object.create(null), {a: 'b', c: 'd'}));
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(parseHeaders('a: b\r\nc: d\r\n').a).toBe('b');
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should parse tab after semi-colon', function() {
expect(parseHeaders('a:\tbb').a).toBe('bb');
expect(parseHeaders('a: \tbb').a).toBe('bb');
});
test($http): parsing headers with multiple values Closes #9473 Closes #10176
2014-11-22 17:43:41 +01:00
it('should parse multiple values for the same header', function() {
expect(parseHeaders('key:value1\nkey:value2').key).toBe('value1, value2');
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
describe('request headers', function() {
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should send custom headers', function() {
$httpBackend.expect('GET', '/url', undefined, function(headers) {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
return headers['Custom'] === 'header';
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
}).respond('');
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$http({url: '/url', method: 'GET', headers: {
style(tests): remove trailing comma in specs Closes #6241
2014-02-13 17:40:29 +08:00
'Custom': 'header'
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
}});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should set default headers for GET request', function() {
$httpBackend.expect('GET', '/url', undefined, function(headers) {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
return headers['Accept'] === 'application/json, text/plain, */*';
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
}).respond('');
feat(mocks.$httpBackend): add $httpBackend mock $httpBackend mock allows: - expecting (asserting) requests - stubbing (responding without asserting) Add empty $httpBackend service (currently just wrapper for $browser.xhr)
2011-08-16 21:24:53 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$http({url: '/url', method: 'GET', headers: {}});
$httpBackend.flush();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should set default headers for POST request', function() {
fix($http): don't send Content-Type header when no data When a http request has no data (body), we should not send the Content-Type header as it causes problems for some server-side frameworks. Closes #749
2012-02-28 12:11:03 -08:00
$httpBackend.expect('POST', '/url', 'messageBody', function(headers) {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
return headers['Accept'] === 'application/json, text/plain, */*' &&
headers['Content-Type'] === 'application/json;charset=utf-8';
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
}).respond('');
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
fix($http): don't send Content-Type header when no data When a http request has no data (body), we should not send the Content-Type header as it causes problems for some server-side frameworks. Closes #749
2012-02-28 12:11:03 -08:00
$http({url: '/url', method: 'POST', headers: {}, data: 'messageBody'});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should set default headers for PUT request', function() {
fix($http): don't send Content-Type header when no data When a http request has no data (body), we should not send the Content-Type header as it causes problems for some server-side frameworks. Closes #749
2012-02-28 12:11:03 -08:00
$httpBackend.expect('PUT', '/url', 'messageBody', function(headers) {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
return headers['Accept'] === 'application/json, text/plain, */*' &&
headers['Content-Type'] === 'application/json;charset=utf-8';
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
}).respond('');
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
fix($http): don't send Content-Type header when no data When a http request has no data (body), we should not send the Content-Type header as it causes problems for some server-side frameworks. Closes #749
2012-02-28 12:11:03 -08:00
$http({url: '/url', method: 'PUT', headers: {}, data: 'messageBody'});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): add a default content type for PATH requests The default header is now application/json which while not perfect in all cases is better than the browser default application/xml. The new headers also makes for better compatibility with Rails 4
2013-05-11 19:23:33 +03:00
it('should set default headers for PATCH request', function() {
$httpBackend.expect('PATCH', '/url', 'messageBody', function(headers) {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
return headers['Accept'] === 'application/json, text/plain, */*' &&
headers['Content-Type'] === 'application/json;charset=utf-8';
feat($http): add a default content type for PATH requests The default header is now application/json which while not perfect in all cases is better than the browser default application/xml. The new headers also makes for better compatibility with Rails 4
2013-05-11 19:23:33 +03:00
}).respond('');
$http({url: '/url', method: 'PATCH', headers: {}, data: 'messageBody'});
$httpBackend.flush();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should set default headers for custom HTTP method', function() {
$httpBackend.expect('FOO', '/url', undefined, function(headers) {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
return headers['Accept'] === 'application/json, text/plain, */*';
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
}).respond('');
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$http({url: '/url', method: 'FOO', headers: {}});
$httpBackend.flush();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should override default headers with custom', function() {
fix($http): don't send Content-Type header when no data When a http request has no data (body), we should not send the Content-Type header as it causes problems for some server-side frameworks. Closes #749
2012-02-28 12:11:03 -08:00
$httpBackend.expect('POST', '/url', 'messageBody', function(headers) {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
return headers['Accept'] === 'Rewritten' &&
headers['Content-Type'] === 'Rewritten';
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
}).respond('');
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
fix($http): don't send Content-Type header when no data When a http request has no data (body), we should not send the Content-Type header as it causes problems for some server-side frameworks. Closes #749
2012-02-28 12:11:03 -08:00
$http({url: '/url', method: 'POST', data: 'messageBody', headers: {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
'Accept': 'Rewritten',
'Content-Type': 'Rewritten'
}});
$httpBackend.flush();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
style(*): add rule disallowSpacesInAnonymousFunctionExpression beforeOpeningRoundBrace, including i18n generator
2014-10-22 17:31:27 -04:00
it('should delete default headers if custom header function returns null', function() {
fix($http) - add ability to remove default headers Fixes #5784 Closes #5785
2014-01-13 22:34:22 -08:00
$httpBackend.expect('POST', '/url', 'messageBody', function(headers) {
return !('Accept' in headers);
}).respond('');
$http({url: '/url', method: 'POST', data: 'messageBody', headers: {
'Accept': function() { return null; }
}});
$httpBackend.flush();
});
fix($http): ensure case-insens. header overriding If user send content-type header, both content-type and default Content-Type headers were sent. Now default header overriding is case-insensitive.
2013-06-19 21:30:28 +01:00
it('should override default headers with custom in a case insensitive manner', function() {
$httpBackend.expect('POST', '/url', 'messageBody', function(headers) {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
return headers['accept'] === 'Rewritten' &&
headers['content-type'] === 'Content-Type Rewritten' &&
refactor(*): use `isDefined` and `isUndefined` consistently Fix any place that compares with `undefined` to use `isUndefined` and `isDefined` instead. Closes #4365 Closes #12831
2015-09-11 22:11:57 -06:00
isUndefined(headers['Accept']) &&
isUndefined(headers['Content-Type']);
fix($http): ensure case-insens. header overriding If user send content-type header, both content-type and default Content-Type headers were sent. Now default header overriding is case-insensitive.
2013-06-19 21:30:28 +01:00
}).respond('');
$http({url: '/url', method: 'POST', data: 'messageBody', headers: {
'accept': 'Rewritten',
'content-type': 'Content-Type Rewritten'
}});
$httpBackend.flush();
});
fix($http): don't send Content-Type header when no data When a http request has no data (body), we should not send the Content-Type header as it causes problems for some server-side frameworks. Closes #749
2012-02-28 12:11:03 -08:00
it('should not send Content-Type header if request data/body is undefined', function() {
$httpBackend.expect('POST', '/url', undefined, function(headers) {
return !headers.hasOwnProperty('Content-Type');
}).respond('');
fix($http): ensure case-insens. header overriding If user send content-type header, both content-type and default Content-Type headers were sent. Now default header overriding is case-insensitive.
2013-06-19 21:30:28 +01:00
$httpBackend.expect('POST', '/url2', undefined, function(headers) {
return !headers.hasOwnProperty('content-type');
}).respond('');
fix($http): allow interceptors to completely override headers Closes #2770
2013-07-12 17:42:37 -07:00
fix($http): don't send Content-Type header when no data When a http request has no data (body), we should not send the Content-Type header as it causes problems for some server-side frameworks. Closes #749
2012-02-28 12:11:03 -08:00
$http({url: '/url', method: 'POST'});
fix($http): ensure case-insens. header overriding If user send content-type header, both content-type and default Content-Type headers were sent. Now default header overriding is case-insensitive.
2013-06-19 21:30:28 +01:00
$http({url: '/url2', method: 'POST', headers: {'content-type': 'Rewritten'}});
fix($http): don't send Content-Type header when no data When a http request has no data (body), we should not send the Content-Type header as it causes problems for some server-side frameworks. Closes #749
2012-02-28 12:11:03 -08:00
$httpBackend.flush();
});
fix($http): don't remove content-type header if data is set by request transform Fixes #7910
2014-06-25 20:34:55 +02:00
it('should NOT delete Content-Type header if request data/body is set by request transform', function() {
style(*): disallow space after object keys, other rules add `disallowSpaceAfterObjectKeys` and associated changes. add `disallowMixedSpacesAndTabs` (no files changed) add `disallowMultipleLineStrings` (no files changed) Closes #9679
2014-10-18 19:48:33 -04:00
$httpBackend.expect('POST', '/url', {'one': 'two'}, function(headers) {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
return headers['Content-Type'] === 'application/json;charset=utf-8';
fix($http): don't remove content-type header if data is set by request transform Fixes #7910
2014-06-25 20:34:55 +02:00
}).respond('');
$http({
url: '/url',
method: 'POST',
style(*): disallow space after object keys, other rules add `disallowSpaceAfterObjectKeys` and associated changes. add `disallowMixedSpacesAndTabs` (no files changed) add `disallowMultipleLineStrings` (no files changed) Closes #9679
2014-10-18 19:48:33 -04:00
transformRequest: function(data) {
data = {'one': 'two'};
fix($http): don't remove content-type header if data is set by request transform Fixes #7910
2014-06-25 20:34:55 +02:00
return data;
}
});
$httpBackend.flush();
});
fix($http): don't send Content-Type header when no data When a http request has no data (body), we should not send the Content-Type header as it causes problems for some server-side frameworks. Closes #749
2012-02-28 12:11:03 -08:00
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
it('should send execute result if header value is function', function() {
feat($http): accept function as headers value So we can request with dynamic header value. module.factory('Res', [ '$resource' '$routeParams' 'globalConfig' function($resource, $routeParams, globalConfig) { resource('/url/:id', {id: "@id"}, { patch: { method: 'patch', headers: { 'Authorization': function() { return "token " + globalConfig.token; } } } }); }]);
2013-07-03 15:51:05 +08:00
var headerConfig = {'Accept': function() { return 'Rewritten'; }};
function checkHeaders(headers) {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
return headers['Accept'] === 'Rewritten';
feat($http): accept function as headers value So we can request with dynamic header value. module.factory('Res', [ '$resource' '$routeParams' 'globalConfig' function($resource, $routeParams, globalConfig) { resource('/url/:id', {id: "@id"}, { patch: { method: 'patch', headers: { 'Authorization': function() { return "token " + globalConfig.token; } } } }); }]);
2013-07-03 15:51:05 +08:00
}
$httpBackend.expect('GET', '/url', undefined, checkHeaders).respond('');
$httpBackend.expect('POST', '/url', undefined, checkHeaders).respond('');
$httpBackend.expect('PUT', '/url', undefined, checkHeaders).respond('');
$httpBackend.expect('PATCH', '/url', undefined, checkHeaders).respond('');
$httpBackend.expect('DELETE', '/url', undefined, checkHeaders).respond('');
$http({url: '/url', method: 'GET', headers: headerConfig});
$http({url: '/url', method: 'POST', headers: headerConfig});
$http({url: '/url', method: 'PUT', headers: headerConfig});
$http({url: '/url', method: 'PATCH', headers: headerConfig});
$http({url: '/url', method: 'DELETE', headers: headerConfig});
$httpBackend.flush();
test($http): remove unused inject() calls Closes #10611
2014-12-31 14:36:54 +01:00
});
perf($http): move xsrf cookie check to after cache check in $http $http was previously checking cookies to find an xsrf-token prior to checking the cache. This caused a performance penalty of about 2ms, which can be very significant when loading hundreds of template instances on a page. Fixes #7717
2014-06-09 15:54:09 +02:00
feat($http): provide a config object as an argument to header functions Closes #7235 Closes #10622
2015-01-02 18:27:21 +01:00
it('should expose a config object to header functions', function() {
var config = {
foo: 'Rewritten',
headers: {'Accept': function(config) {
return config.foo;
}}
};
$httpBackend.expect('GET', '/url', undefined, {Accept: 'Rewritten'}).respond('');
$http.get('/url', config);
$httpBackend.flush();
});
it('should not allow modifications to a config object in header functions', function() {
var config = {
headers: {'Accept': function(config) {
config.foo = 'bar';
return 'Rewritten';
}}
};
$httpBackend.expect('GET', '/url', undefined, {Accept: 'Rewritten'}).respond('');
$http.get('/url', config);
$httpBackend.flush();
expect(config.foo).toBeUndefined();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
describe('short methods', function() {
function checkHeader(name, value) {
feat(mocks.$httpBackend): add $httpBackend mock $httpBackend mock allows: - expecting (asserting) requests - stubbing (responding without asserting) Add empty $httpBackend service (currently just wrapper for $browser.xhr)
2011-08-16 21:24:53 +02:00
return function(headers) {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
return headers[name] === value;
feat(mocks.$httpBackend): add $httpBackend mock $httpBackend mock allows: - expecting (asserting) requests - stubbing (responding without asserting) Add empty $httpBackend service (currently just wrapper for $browser.xhr)
2011-08-16 21:24:53 +02:00
};
}
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should have get()', function() {
$httpBackend.expect('GET', '/url').respond('');
$http.get('/url');
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat(mocks.$httpBackend): add $httpBackend mock $httpBackend mock allows: - expecting (asserting) requests - stubbing (responding without asserting) Add empty $httpBackend service (currently just wrapper for $browser.xhr)
2011-08-16 21:24:53 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('get() should allow config param', function() {
$httpBackend.expect('GET', '/url', undefined, checkHeader('Custom', 'Header')).respond('');
$http.get('/url', {headers: {'Custom': 'Header'}});
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
fix($http): return empty headers, ignore properties in Object prototype Fix response headers with an empty value Empty response header values are legal (http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html). The headers getter fn will now only return null if the header property is not an own property. Closes #7779 Closes #10113 Closes #10091
2014-11-17 03:29:22 -06:00
it('should handle empty response header', function() {
$httpBackend.expect('GET', '/url', undefined)
.respond(200, '', { 'Custom-Empty-Response-Header': '', 'Constructor': '' });
test($http): remove use of deprecated `success` and `error` calls in tests
2015-09-07 14:43:33 +01:00
$http.get('/url').then(callback);
fix($http): return empty headers, ignore properties in Object prototype Fix response headers with an empty value Empty response header values are legal (http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html). The headers getter fn will now only return null if the header property is not an own property. Closes #7779 Closes #10113 Closes #10091
2014-11-17 03:29:22 -06:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
var headers = callback.calls.mostRecent().args[0].headers;
test($http): remove use of deprecated `success` and `error` calls in tests
2015-09-07 14:43:33 +01:00
expect(headers('custom-empty-response-Header')).toEqual('');
expect(headers('ToString')).toBe(null);
expect(headers('Constructor')).toBe('');
fix($http): return empty headers, ignore properties in Object prototype Fix response headers with an empty value Empty response header values are legal (http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html). The headers getter fn will now only return null if the header property is not an own property. Closes #7779 Closes #10113 Closes #10091
2014-11-17 03:29:22 -06:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should have delete()', function() {
$httpBackend.expect('DELETE', '/url').respond('');
$http['delete']('/url');
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('delete() should allow config param', function() {
$httpBackend.expect('DELETE', '/url', undefined, checkHeader('Custom', 'Header')).respond('');
$http['delete']('/url', {headers: {'Custom': 'Header'}});
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should have head()', function() {
$httpBackend.expect('HEAD', '/url').respond('');
$http.head('/url');
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('head() should allow config param', function() {
$httpBackend.expect('HEAD', '/url', undefined, checkHeader('Custom', 'Header')).respond('');
$http.head('/url', {headers: {'Custom': 'Header'}});
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should have post()', function() {
$httpBackend.expect('POST', '/url', 'some-data').respond('');
$http.post('/url', 'some-data');
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('post() should allow config param', function() {
$httpBackend.expect('POST', '/url', 'some-data', checkHeader('Custom', 'Header')).respond('');
$http.post('/url', 'some-data', {headers: {'Custom': 'Header'}});
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should have put()', function() {
$httpBackend.expect('PUT', '/url', 'some-data').respond('');
$http.put('/url', 'some-data');
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('put() should allow config param', function() {
$httpBackend.expect('PUT', '/url', 'some-data', checkHeader('Custom', 'Header')).respond('');
$http.put('/url', 'some-data', {headers: {'Custom': 'Header'}});
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
style(*): add rule requireSpacesInFunction beforeOpeningCurlyBrace This rule enforces a space after the curly brace for function declarations, anonymous function expressions, and named function expressions.
2014-10-20 21:59:40 -04:00
it('should have patch()', function() {
fix($http): add the PATCH shortcut back The shortcut was dropped because it had a lot of unkowns about PATCH. Since we already know that using PATCH is good (http://www.mnot.net/blog/2012/09/05/patch), and only IE8 has issues with that, let's add the shortcut back. Closes #5894
2014-01-20 11:21:31 -02:00
$httpBackend.expect('PATCH', '/url', 'some-data').respond('');
$http.patch('/url', 'some-data');
});
it('patch() should allow config param', function() {
$httpBackend.expect('PATCH', '/url', 'some-data', checkHeader('Custom', 'Header')).respond('');
$http.patch('/url', 'some-data', {headers: {'Custom': 'Header'}});
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should have jsonp()', function() {
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
$httpBackend.expect('JSONP', '/url?callback=JSON_CALLBACK').respond('');
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
$http.jsonp($sce.trustAsResourceUrl('/url'));
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('jsonp() should allow config param', function() {
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
$httpBackend.expect('JSONP', '/url?callback=JSON_CALLBACK', undefined, checkHeader('Custom', 'Header')).respond('');
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
$http.jsonp($sce.trustAsResourceUrl('/url'), {headers: {'Custom': 'Header'}});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
describe('jsonp trust', function() {
it('should throw error if the url is not a trusted resource', function() {
var success, error;
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
$http({method: 'JSONP', url: 'http://example.org/path'})
.catch(function(e) { error = e; });
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
$rootScope.$digest();
test(*): introduce the `toEqualMinErr()` custom Jasmine matcher Closes #15216
2016-10-05 17:32:37 +03:00
expect(error).toEqualMinErr('$sce', 'insecurl');
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
});
it('should accept an explicitly trusted resource url', function() {
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
$httpBackend.expect('JSONP', 'http://example.org/path?callback=JSON_CALLBACK').respond('');
$http({ method: 'JSONP', url: $sce.trustAsResourceUrl('http://example.org/path')});
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
});
docs(*): fix typos * a * allows * angularytics * animate * architecting * asynchronously * attribute * back * browser * callback * component * delimited * dependencies * dynamically * empty * encoded * explicitly * expression * fails * guarantees * hierarchy * highlight * identifiers * immediately * infinite * initialized * inputting * instance * interprets * linking * location * misformed * numerically * occurring * overridden * overwritten * parameters * Pluralsight * precedence * primitive * properly * prototypically * representation * response * separately * separator * should * specifying * supported * template * thrown * transclude * transclusion * transitions * trigger * useful
2016-10-28 10:51:03 +00:00
it('jsonp() should accept explicitly trusted urls', function() {
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
$httpBackend.expect('JSONP', '/url?callback=JSON_CALLBACK').respond('');
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
$http({method: 'JSONP', url: $sce.trustAsResourceUrl('/url')});
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
$httpBackend.expect('JSONP', '/url?a=b&callback=JSON_CALLBACK').respond('');
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
$http({method: 'JSONP', url: $sce.trustAsResourceUrl('/url'), params: {a: 'b'}});
});
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
fix(http): do not allow encoded callback params in jsonp requests
2017-08-28 22:11:19 +01:00
it('should error if the URL contains more than one `?` query indicator', function() {
var error;
$http({ method: 'JSONP', url: $sce.trustAsResourceUrl('http://example.org/path?a=b?c=d')})
.catch(function(e) { error = e; });
$rootScope.$digest();
expect(error).toEqualMinErr('$http', 'badjsonp');
});
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
it('should error if the URL contains a JSON_CALLBACK parameter', function() {
var error;
$http({ method: 'JSONP', url: $sce.trustAsResourceUrl('http://example.org/path?callback=JSON_CALLBACK')})
.catch(function(e) { error = e; });
$rootScope.$digest();
test(*): introduce the `toEqualMinErr()` custom Jasmine matcher Closes #15216
2016-10-05 17:32:37 +03:00
expect(error).toEqualMinErr('$http', 'badjsonp');
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
fix(http): do not allow encoded callback params in jsonp requests
2017-08-28 22:11:19 +01:00
error = undefined;
$http({ method: 'JSONP', url: $sce.trustAsResourceUrl('http://example.org/path?callback=JSON_C%41LLBACK')})
.catch(function(e) { error = e; });
$rootScope.$digest();
expect(error).toEqualMinErr('$http', 'badjsonp');
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
error = undefined;
$http({ method: 'JSONP', url: $sce.trustAsResourceUrl('http://example.org/path?other=JSON_CALLBACK')})
.catch(function(e) { error = e; });
$rootScope.$digest();
test(*): introduce the `toEqualMinErr()` custom Jasmine matcher Closes #15216
2016-10-05 17:32:37 +03:00
expect(error).toEqualMinErr('$http', 'badjsonp');
fix(http): do not allow encoded callback params in jsonp requests
2017-08-28 22:11:19 +01:00
error = undefined;
$http({ method: 'JSONP', url: $sce.trustAsResourceUrl('http://example.org/path?other=JSON_C%41LLBACK')})
.catch(function(e) { error = e; });
$rootScope.$digest();
expect(error).toEqualMinErr('$http', 'badjsonp');
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
});
it('should error if a param contains a JSON_CALLBACK value', function() {
var error;
$http({ method: 'JSONP', url: $sce.trustAsResourceUrl('http://example.org/path'), params: {callback: 'JSON_CALLBACK'}})
.catch(function(e) { error = e; });
$rootScope.$digest();
test(*): introduce the `toEqualMinErr()` custom Jasmine matcher Closes #15216
2016-10-05 17:32:37 +03:00
expect(error).toEqualMinErr('$http', 'badjsonp');
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
error = undefined;
$http({ method: 'JSONP', url: $sce.trustAsResourceUrl('http://example.org/path'), params: {other: 'JSON_CALLBACK'}})
.catch(function(e) { error = e; });
$rootScope.$digest();
test(*): introduce the `toEqualMinErr()` custom Jasmine matcher Closes #15216
2016-10-05 17:32:37 +03:00
expect(error).toEqualMinErr('$http', 'badjsonp');
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
});
fix(http): do not allow encoded callback params in jsonp requests
2017-08-28 22:11:19 +01:00
it('should allow encoded params that look like they contain the value JSON_CALLBACK or the configured callback key', function() {
var error;
error = undefined;
$httpBackend.expect('JSONP', 'http://example.org/path?other=JSON_C%2541LLBACK&callback=JSON_CALLBACK').respond('');
$http({ method: 'JSONP', url: $sce.trustAsResourceUrl('http://example.org/path'), params: {other: 'JSON_C%41LLBACK'}})
.catch(function(e) { error = e; });
$rootScope.$digest();
expect(error).toBeUndefined();
error = undefined;
$httpBackend.expect('JSONP', 'http://example.org/path?c%2561llback=evilThing&callback=JSON_CALLBACK').respond('');
$http({ method: 'JSONP', url: $sce.trustAsResourceUrl('http://example.org/path'), params: {'c%61llback': 'evilThing'}})
.catch(function(e) { error = e; });
$rootScope.$digest();
expect(error).toBeUndefined();
});
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
it('should error if there is already a param matching the jsonpCallbackParam key', function() {
var error;
$http({ method: 'JSONP', url: $sce.trustAsResourceUrl('http://example.org/path'), params: {callback: 'evilThing'}})
.catch(function(e) { error = e; });
$rootScope.$digest();
test(*): introduce the `toEqualMinErr()` custom Jasmine matcher Closes #15216
2016-10-05 17:32:37 +03:00
expect(error).toEqualMinErr('$http', 'badjsonp');
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
fix(http): do not allow encoded callback params in jsonp requests
2017-08-28 22:11:19 +01:00
error = undefined;
$http({ method: 'JSONP', url: $sce.trustAsResourceUrl('http://example.org/path?c%61llback=evilThing')})
.catch(function(e) { error = e; });
$rootScope.$digest();
expect(error).toEqualMinErr('$http', 'badjsonp');
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
error = undefined;
$http({ method: 'JSONP', jsonpCallbackParam: 'cb', url: $sce.trustAsResourceUrl('http://example.org/path'), params: {cb: 'evilThing'}})
.catch(function(e) { error = e; });
$rootScope.$digest();
test(*): introduce the `toEqualMinErr()` custom Jasmine matcher Closes #15216
2016-10-05 17:32:37 +03:00
expect(error).toEqualMinErr('$http', 'badjsonp');
fix(http): do not allow encoded callback params in jsonp requests
2017-08-28 22:11:19 +01:00
error = undefined;
$http({ method: 'JSONP', jsonpCallbackParam: 'cb', url: $sce.trustAsResourceUrl('http://example.org/path?c%62=evilThing')})
.catch(function(e) { error = e; });
$rootScope.$digest();
expect(error).toEqualMinErr('$http', 'badjsonp');
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
});
feat($http): JSONP requests now require a trusted resource URL The $http service will reject JSONP requests that are not trusted by `$sce` as "ResourceUrl". This change makes is easier for developers to see clearly where in their code they are making JSONP calls that may be to untrusted endpoings and forces them to think about how these URLs are generated. Be aware that this commit does not put any constraint on the parameters that will be appended to the URL. Developers should be mindful of what parameters can be attached and how they are generated. Closes #11352 BREAKING CHANGE All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL: **Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()` method.** You configure this list in a module configuration block: ``` appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) { $sceDelegateProvider.resourceUrlWhiteList([ // Allow same origin resource loads. 'self', // Allow JSONP calls that match this pattern 'https://some.dataserver.com/**.jsonp?**` ]); }]); ``` **Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)` method** You can pass a trusted object instead of a string as a URL to the `$http` service: ``` var promise = $http.jsonp($sce.trustAsResourceUrl(url)); ```
2016-09-20 18:41:22 +01:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): support handling additional XHR events Closes #14367 Closes #11547 Closes #1934
2016-04-04 13:48:43 +01:00
describe('callbacks', function() {
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should $apply after success callback', function() {
$httpBackend.when('GET').respond(200);
$http({method: 'GET', url: '/some'});
$httpBackend.flush();
expect($rootScope.$apply).toHaveBeenCalledOnce();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should $apply after error callback', function() {
$httpBackend.when('GET').respond(404);
feat($q): report promises with non rejection callback Rejected promises that do not have a callback to handle the rejection report this to $exceptionHandler so they can be logged to the console. BREAKING CHANGE Unhandled rejected promises will be logged to $exceptionHandler. Tests that depend on specific order or number of messages in $exceptionHandler will need to handle rejected promises report. Closes: #13653 Closes: #7992
2016-01-01 23:40:00 +01:00
$http({method: 'GET', url: '/some'}).catch(noop);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
expect($rootScope.$apply).toHaveBeenCalledOnce();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
style(*): add rule requireSpacesInFunction beforeOpeningCurlyBrace This rule enforces a space after the curly brace for function declarations, anonymous function expressions, and named function expressions.
2014-10-20 21:59:40 -04:00
it('should $apply even if exception thrown during callback', inject(function($exceptionHandler) {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.when('GET').respond(200);
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
callback.and.throwError('error in callback');
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$http({method: 'GET', url: '/some'}).then(callback);
$httpBackend.flush();
expect($rootScope.$apply).toHaveBeenCalledOnce();
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$exceptionHandler.errors = [];
}));
feat($http): support handling additional XHR events Closes #14367 Closes #11547 Closes #1934
2016-04-04 13:48:43 +01:00
it('should pass the event handlers through to the backend', function() {
var progressFn = jasmine.createSpy('progressFn');
var uploadProgressFn = jasmine.createSpy('uploadProgressFn');
$httpBackend.when('GET').respond(200);
$http({
method: 'GET',
url: '/some',
eventHandlers: {progress: progressFn},
uploadEventHandlers: {progress: uploadProgressFn}
});
$rootScope.$apply();
var mockXHR = MockXhr.$$lastInstance;
expect(mockXHR.$$events.progress).toEqual(jasmine.any(Function));
expect(mockXHR.upload.$$events.progress).toEqual(jasmine.any(Function));
fix($http): pass event object to `eventHandlers`/`uploadEventHandlers` Fixes #14436
2016-04-14 23:14:26 +03:00
var eventObj = {};
feat($http): support handling additional XHR events Closes #14367 Closes #11547 Closes #1934
2016-04-04 13:48:43 +01:00
spyOn($rootScope, '$digest');
fix($http): pass event object to `eventHandlers`/`uploadEventHandlers` Fixes #14436
2016-04-14 23:14:26 +03:00
mockXHR.$$events.progress(eventObj);
expect(progressFn).toHaveBeenCalledOnceWith(eventObj);
feat($http): support handling additional XHR events Closes #14367 Closes #11547 Closes #1934
2016-04-04 13:48:43 +01:00
expect($rootScope.$digest).toHaveBeenCalledTimes(1);
fix($http): pass event object to `eventHandlers`/`uploadEventHandlers` Fixes #14436
2016-04-14 23:14:26 +03:00
mockXHR.upload.$$events.progress(eventObj);
expect(uploadProgressFn).toHaveBeenCalledOnceWith(eventObj);
feat($http): support handling additional XHR events Closes #14367 Closes #11547 Closes #1934
2016-04-04 13:48:43 +01:00
expect($rootScope.$digest).toHaveBeenCalledTimes(2);
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
describe('transformData', function() {
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
describe('request', function() {
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
describe('default', function() {
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should transform object into json', function() {
$httpBackend.expect('POST', '/url', '{"one":"two"}').respond('');
$http({method: 'POST', url: '/url', data: {one: 'two'}});
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): broadcast $http.request event
2011-10-31 12:03:09 -07:00
fix(ngMock): $httpBackend should match data containing Date objects correctly If a response or expectation contained a date object then `$httpBackend.expect` was not matching correctly. This commit encodes then decodes the object being matched to ensure consistency. Closes #5127
2013-11-25 18:00:21 +01:00
it('should transform object with date into json', function() {
chore(eslint): enable `quotes: ["error", "single"]` The quotes rule had to be disabled for e2e tests generated from ngdoc because dgeni templates use double quotes as string delimiters. Since we can't have guarantees that dgeni template wrappers will follow the same JS code style the Angular 1 repo uses, we should find a way to enforce our ESLint setup only for the parts in this repo, perhaps via prepending a generated `/* eslint-enable OUR_RULES */` pragma. Closes #15011
2016-08-10 12:13:14 +02:00
$httpBackend.expect('POST', '/url', {'date': new Date(Date.UTC(2013, 11, 25))}).respond('');
fix(ngMock): $httpBackend should match data containing Date objects correctly If a response or expectation contained a date object then `$httpBackend.expect` was not matching correctly. This commit encodes then decodes the object being matched to ensure consistency. Closes #5127
2013-11-25 18:00:21 +01:00
$http({method: 'POST', url: '/url', data: {date: new Date(Date.UTC(2013, 11, 25))}});
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should ignore strings', function() {
$httpBackend.expect('POST', '/url', 'string-data').respond('');
$http({method: 'POST', url: '/url', data: 'string-data'});
});
fix($http): Do not serialize File object
2012-02-25 18:49:54 -08:00
it('should ignore File objects', function() {
var file = {
some: true,
// $httpBackend compares toJson values by default,
// we need to be sure it's not serialized into json string
test: function(actualValue) {
return this === actualValue;
}
};
// I'm really sorry for doing this :-D
docs: fix typos throughout the codebase Closes #13519
2015-12-12 00:26:17 +02:00
// Unfortunately I don't know how to trick toString.apply(obj) comparison
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
spyOn(window, 'isFile').and.returnValue(true);
fix($http): Do not serialize File object
2012-02-25 18:49:54 -08:00
$httpBackend.expect('POST', '/some', file).respond('');
$http({method: 'POST', url: '/some', data: file});
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): expose req/resp headers to transform fns
2012-01-04 09:21:05 -08:00
style(*): add rule disallowSpacesInAnonymousFunctionExpression beforeOpeningRoundBrace, including i18n generator
2014-10-22 17:31:27 -04:00
it('should ignore Blob objects', function() {
fix($http): allow sending Blob data using $http Closes #5012
2013-11-19 00:30:36 +01:00
if (!window.Blob) return;
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
// eslint-disable-next-line no-undef
fix($http): allow sending Blob data using $http Closes #5012
2013-11-19 00:30:36 +01:00
var blob = new Blob(['blob!'], { type: 'text/plain' });
$httpBackend.expect('POST', '/url', '[object Blob]').respond('');
$http({ method: 'POST', url: '/url', data: blob });
});
fix($http): don't convert FormData objects to JSON This won't enable FormData uploads in itself, as the Content-Type is automatically set to application/json. Closes #10373
2014-12-08 23:25:45 +01:00
it('should ignore FormData objects', function() {
if (!window.FormData) return;
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
// eslint-disable-next-line no-undef
fix($http): don't convert FormData objects to JSON This won't enable FormData uploads in itself, as the Content-Type is automatically set to application/json. Closes #10373
2014-12-08 23:25:45 +01:00
var formData = new FormData();
formData.append('angular', 'is great');
$httpBackend.expect('POST', '/url', '[object FormData]').respond('');
$http({ method: 'POST', url: '/url', data: formData });
});
fix($http): allow sending Blob data using $http Closes #5012
2013-11-19 00:30:36 +01:00
feat($http): expose req/resp headers to transform fns
2012-01-04 09:21:05 -08:00
it('should have access to request headers', function() {
$httpBackend.expect('POST', '/url', 'header1').respond(200);
$http.post('/url', 'req', {
headers: {h1: 'header1'},
transformRequest: function(data, headers) {
return headers('h1');
}
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
}).then(callback);
feat($http): expose req/resp headers to transform fns
2012-01-04 09:21:05 -08:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
});
fix($http): properly access request headers with mixed case Fixes #10881 Closes #10883
2015-02-20 19:01:44 +01:00
it('should have access to request headers with mixed case', function() {
$httpBackend.expect('POST', '/url', 'header1').respond(200);
$http.post('/url', 'req', {
headers: {H1: 'header1'},
transformRequest: function(data, headers) {
return headers('H1');
}
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
}).then(callback);
fix($http): properly access request headers with mixed case Fixes #10881 Closes #10883
2015-02-20 19:01:44 +01:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
});
feat($http): expose req/resp headers to transform fns
2012-01-04 09:21:05 -08:00
docs($http): clarify side effects of transformRequest functions Closes #11438 Closes #11503
2015-04-03 12:27:27 +02:00
it('should not allow modifications to headers in a transform functions', function() {
var config = {
headers: {'Accept': 'bar'},
transformRequest: function(data, headers) {
angular.extend(headers(), {
'Accept': 'foo'
});
}
};
$httpBackend.expect('GET', '/url', undefined, {Accept: 'bar'}).respond(200);
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http.get('/url', config).then(callback);
docs($http): clarify side effects of transformRequest functions Closes #11438 Closes #11503
2015-04-03 12:27:27 +02:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
});
feat($http): expose req/resp headers to transform fns
2012-01-04 09:21:05 -08:00
it('should pipeline more functions', function() {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
function first(d, h) {return d + '-first:' + h('h1');}
chore(jshint): enforce jshint for tests Closes #7264
2014-04-26 23:07:28 +03:00
function second(d) {return uppercase(d);}
feat($http): expose req/resp headers to transform fns
2012-01-04 09:21:05 -08:00
$httpBackend.expect('POST', '/url', 'REQ-FIRST:V1').respond(200);
$http.post('/url', 'req', {
headers: {h1: 'v1'},
transformRequest: [first, second]
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
}).then(callback);
feat($http): expose req/resp headers to transform fns
2012-01-04 09:21:05 -08:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): broadcast $http.request event
2011-10-31 12:03:09 -07:00
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
describe('response', function() {
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
describe('default', function() {
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should deserialize json objects', function() {
$httpBackend.expect('GET', '/url').respond('{"foo":"bar","baz":23}');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual({foo: 'bar', baz: 23});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should deserialize json arrays', function() {
$httpBackend.expect('GET', '/url').respond('[1, "abc", {"foo":"bar"}]');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual([1, 'abc', {foo: 'bar'}]);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
fix($http): only parse as JSON when opening/closing brackets match Previously, due to weak JSON-detecting RegExp, string like `[...}` and `{...]` would be considered JSON (even if they obviously aren't) and an expection would be thrown while trying to parse them. This commit makes sure the opening and closing brackets match. This doesn't completely eliminate false positives (e.g. `[]{}[]`), but does help reduce them. Closes #10349 Closes #10357
2014-12-07 14:53:08 +02:00
it('should ignore leading/trailing whitespace', function() {
$httpBackend.expect('GET', '/url').respond(' \n {"foo":"bar","baz":23} \r\n \n ');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
fix($http): only parse as JSON when opening/closing brackets match Previously, due to weak JSON-detecting RegExp, string like `[...}` and `{...]` would be considered JSON (even if they obviously aren't) and an expection would be thrown while trying to parse them. This commit makes sure the opening and closing brackets match. This doesn't completely eliminate false positives (e.g. `[]{}[]`), but does help reduce them. Closes #10349 Closes #10357
2014-12-07 14:53:08 +02:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual({foo: 'bar', baz: 23});
fix($http): only parse as JSON when opening/closing brackets match Previously, due to weak JSON-detecting RegExp, string like `[...}` and `{...]` would be considered JSON (even if they obviously aren't) and an expection would be thrown while trying to parse them. This commit makes sure the opening and closing brackets match. This doesn't completely eliminate false positives (e.g. `[]{}[]`), but does help reduce them. Closes #10349 Closes #10357
2014-12-07 14:53:08 +02:00
});
fix($http): honor application/json response header and parse json primitives When server responds with Content-Type header set to application/json we now properly parse the response as JSON Closes #2973
2014-10-02 13:46:22 -07:00
it('should deserialize json numbers when response header contains application/json',
function() {
$httpBackend.expect('GET', '/url').respond('123', {'Content-Type': 'application/json'});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
fix($http): honor application/json response header and parse json primitives When server responds with Content-Type header set to application/json we now properly parse the response as JSON Closes #2973
2014-10-02 13:46:22 -07:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual(123);
fix($http): honor application/json response header and parse json primitives When server responds with Content-Type header set to application/json we now properly parse the response as JSON Closes #2973
2014-10-02 13:46:22 -07:00
});
it('should deserialize json strings when response header contains application/json',
function() {
$httpBackend.expect('GET', '/url').respond('"asdf"', {'Content-Type': 'application/json'});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
fix($http): honor application/json response header and parse json primitives When server responds with Content-Type header set to application/json we now properly parse the response as JSON Closes #2973
2014-10-02 13:46:22 -07:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual('asdf');
fix($http): honor application/json response header and parse json primitives When server responds with Content-Type header set to application/json we now properly parse the response as JSON Closes #2973
2014-10-02 13:46:22 -07:00
});
it('should deserialize json nulls when response header contains application/json',
function() {
$httpBackend.expect('GET', '/url').respond('null', {'Content-Type': 'application/json'});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
fix($http): honor application/json response header and parse json primitives When server responds with Content-Type header set to application/json we now properly parse the response as JSON Closes #2973
2014-10-02 13:46:22 -07:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual(null);
fix($http): honor application/json response header and parse json primitives When server responds with Content-Type header set to application/json we now properly parse the response as JSON Closes #2973
2014-10-02 13:46:22 -07:00
});
it('should deserialize json true when response header contains application/json',
function() {
$httpBackend.expect('GET', '/url').respond('true', {'Content-Type': 'application/json'});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
fix($http): honor application/json response header and parse json primitives When server responds with Content-Type header set to application/json we now properly parse the response as JSON Closes #2973
2014-10-02 13:46:22 -07:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual(true);
fix($http): honor application/json response header and parse json primitives When server responds with Content-Type header set to application/json we now properly parse the response as JSON Closes #2973
2014-10-02 13:46:22 -07:00
});
it('should deserialize json false when response header contains application/json',
function() {
$httpBackend.expect('GET', '/url').respond('false', {'Content-Type': 'application/json'});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
fix($http): honor application/json response header and parse json primitives When server responds with Content-Type header set to application/json we now properly parse the response as JSON Closes #2973
2014-10-02 13:46:22 -07:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual(false);
fix($http): honor application/json response header and parse json primitives When server responds with Content-Type header set to application/json we now properly parse the response as JSON Closes #2973
2014-10-02 13:46:22 -07:00
});
fix($http): don't run transformData on HEAD methods 7b6c1d0 created this issue by using `Content-Type` to determine when to run `fromJson`. Because `HEAD` methods do not contain a body but are supposed to return the `Content-Type` header that would have been returned if it was a `GET` this functionality fails. Closes #9528 Closes #9529
2014-10-09 13:43:36 -05:00
it('should deserialize json empty string when response header contains application/json',
function() {
$httpBackend.expect('GET', '/url').respond('""', {'Content-Type': 'application/json'});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
fix($http): don't run transformData on HEAD methods 7b6c1d0 created this issue by using `Content-Type` to determine when to run `fromJson`. Because `HEAD` methods do not contain a body but are supposed to return the `Content-Type` header that would have been returned if it was a `GET` this functionality fails. Closes #9528 Closes #9529
2014-10-09 13:43:36 -05:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual('');
fix($http): don't run transformData on HEAD methods 7b6c1d0 created this issue by using `Content-Type` to determine when to run `fromJson`. Because `HEAD` methods do not contain a body but are supposed to return the `Content-Type` header that would have been returned if it was a `GET` this functionality fails. Closes #9528 Closes #9529
2014-10-09 13:43:36 -05:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should deserialize json with security prefix', function() {
$httpBackend.expect('GET', '/url').respond(')]}\',\n[1, "abc", {"foo":"bar"}]');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual([1, 'abc', {foo:'bar'}]);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should deserialize json with security prefix ")]}\'"', function() {
$httpBackend.expect('GET', '/url').respond(')]}\'\n\n[1, "abc", {"foo":"bar"}]');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual([1, 'abc', {foo:'bar'}]);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
fix($http): only parse as JSON when opening/closing brackets match Previously, due to weak JSON-detecting RegExp, string like `[...}` and `{...]` would be considered JSON (even if they obviously aren't) and an expection would be thrown while trying to parse them. This commit makes sure the opening and closing brackets match. This doesn't completely eliminate false positives (e.g. `[]{}[]`), but does help reduce them. Closes #10349 Closes #10357
2014-12-07 14:53:08 +02:00
it('should retain security prefix if response is not json', function() {
$httpBackend.expect('GET', '/url').respond(')]}\',\n This is not JSON !');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
fix($http): only parse as JSON when opening/closing brackets match Previously, due to weak JSON-detecting RegExp, string like `[...}` and `{...]` would be considered JSON (even if they obviously aren't) and an expection would be thrown while trying to parse them. This commit makes sure the opening and closing brackets match. This doesn't completely eliminate false positives (e.g. `[]{}[]`), but does help reduce them. Closes #10349 Closes #10357
2014-12-07 14:53:08 +02:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual(')]}\',\n This is not JSON !');
fix($http): only parse as JSON when opening/closing brackets match Previously, due to weak JSON-detecting RegExp, string like `[...}` and `{...]` would be considered JSON (even if they obviously aren't) and an expection would be thrown while trying to parse them. This commit makes sure the opening and closing brackets match. This doesn't completely eliminate false positives (e.g. `[]{}[]`), but does help reduce them. Closes #10349 Closes #10357
2014-12-07 14:53:08 +02:00
});
style(*): add rule requireSpacesInFunction beforeOpeningCurlyBrace This rule enforces a space after the curly brace for function declarations, anonymous function expressions, and named function expressions.
2014-10-20 21:59:40 -04:00
it('should not attempt to deserialize json when HEAD request', function() {
fix($http): don't run transformData on HEAD methods 7b6c1d0 created this issue by using `Content-Type` to determine when to run `fromJson`. Because `HEAD` methods do not contain a body but are supposed to return the `Content-Type` header that would have been returned if it was a `GET` this functionality fails. Closes #9528 Closes #9529
2014-10-09 13:43:36 -05:00
//per http spec for Content-Type, HEAD request should return a Content-Type header
//set to what the content type would have been if a get was sent
$httpBackend.expect('HEAD', '/url').respond('', {'Content-Type': 'application/json'});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'HEAD', url: '/url'}).then(callback);
fix($http): don't run transformData on HEAD methods 7b6c1d0 created this issue by using `Content-Type` to determine when to run `fromJson`. Because `HEAD` methods do not contain a body but are supposed to return the `Content-Type` header that would have been returned if it was a `GET` this functionality fails. Closes #9528 Closes #9529
2014-10-09 13:43:36 -05:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual('');
fix($http): don't run transformData on HEAD methods 7b6c1d0 created this issue by using `Content-Type` to determine when to run `fromJson`. Because `HEAD` methods do not contain a body but are supposed to return the `Content-Type` header that would have been returned if it was a `GET` this functionality fails. Closes #9528 Closes #9529
2014-10-09 13:43:36 -05:00
});
style(*): add rule requireSpacesInFunction beforeOpeningCurlyBrace This rule enforces a space after the curly brace for function declarations, anonymous function expressions, and named function expressions.
2014-10-20 21:59:40 -04:00
it('should not attempt to deserialize json for an empty response whose header contains application/json', function() {
fix($http): allow empty json response When a response contains an `application/json` header and the response is empty the response should be left as is. Fixes #9532 Closes #9562
2014-10-10 12:10:20 -07:00
//per http spec for Content-Type, HEAD request should return a Content-Type header
//set to what the content type would have been if a get was sent
$httpBackend.expect('GET', '/url').respond('', {'Content-Type': 'application/json'});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
fix($http): allow empty json response When a response contains an `application/json` header and the response is empty the response should be left as is. Fixes #9532 Closes #9562
2014-10-10 12:10:20 -07:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual('');
fix($http): allow empty json response When a response contains an `application/json` header and the response is empty the response should be left as is. Fixes #9532 Closes #9562
2014-10-10 12:10:20 -07:00
});
fix($http): don't run transformData on HEAD methods 7b6c1d0 created this issue by using `Content-Type` to determine when to run `fromJson`. Because `HEAD` methods do not contain a body but are supposed to return the `Content-Type` header that would have been returned if it was a `GET` this functionality fails. Closes #9528 Closes #9529
2014-10-09 13:43:36 -05:00
fix($http): don't parse single space responses as JSON Closes #9907
2014-11-04 19:22:52 +00:00
it('should not attempt to deserialize json for a blank response whose header contains application/json', function() {
//per http spec for Content-Type, HEAD request should return a Content-Type header
//set to what the content type would have been if a get was sent
$httpBackend.expect('GET', '/url').respond(' ', {'Content-Type': 'application/json'});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url'}).then(callback);
fix($http): don't parse single space responses as JSON Closes #9907
2014-11-04 19:22:52 +00:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual(' ');
fix($http): don't parse single space responses as JSON Closes #9907
2014-11-04 19:22:52 +00:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should not deserialize tpl beginning with ng expression', function() {
$httpBackend.expect('GET', '/url').respond('{{some}}');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http.get('/url').then(callback);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toEqual('{{some}}');
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
fix($http): only parse as JSON when opening/closing brackets match Previously, due to weak JSON-detecting RegExp, string like `[...}` and `{...]` would be considered JSON (even if they obviously aren't) and an expection would be thrown while trying to parse them. This commit makes sure the opening and closing brackets match. This doesn't completely eliminate false positives (e.g. `[]{}[]`), but does help reduce them. Closes #10349 Closes #10357
2014-12-07 14:53:08 +02:00
it('should not deserialize json when the opening and closing brackets do not match',
function() {
$httpBackend.expect('GET', '/url1').respond('[Code](url): function() {}');
$httpBackend.expect('GET', '/url2').respond('{"is": "not"} ["json"]');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http.get('/url1').then(callback);
$http.get('/url2').then(callback);
fix($http): only parse as JSON when opening/closing brackets match Previously, due to weak JSON-detecting RegExp, string like `[...}` and `{...]` would be considered JSON (even if they obviously aren't) and an expection would be thrown while trying to parse them. This commit makes sure the opening and closing brackets match. This doesn't completely eliminate false positives (e.g. `[]{}[]`), but does help reduce them. Closes #10349 Closes #10357
2014-12-07 14:53:08 +02:00
$httpBackend.flush();
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
expect(callback).toHaveBeenCalledTimes(2);
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.argsFor(0)[0].data).toEqual('[Code](url): function() {}');
expect(callback.calls.argsFor(1)[0].data).toEqual('{"is": "not"} ["json"]');
fix($http): only parse as JSON when opening/closing brackets match Previously, due to weak JSON-detecting RegExp, string like `[...}` and `{...]` would be considered JSON (even if they obviously aren't) and an expection would be thrown while trying to parse them. This commit makes sure the opening and closing brackets match. This doesn't completely eliminate false positives (e.g. `[]{}[]`), but does help reduce them. Closes #10349 Closes #10357
2014-12-07 14:53:08 +02:00
}
);
test($http): ensure json deserialization errors are forwarded to error handler Since https://github.com/angular/angular.js/commit/e13eeabd7e34a78becec06cfbe72c23f2dcb85f9, errors thrown from onFulfilled and onRejected handlers are passed to the regular http error handlers. Before this, JSON deserialization errors lead to hard application errors, and could not be handled by application code. This behavior was introduced in https://github.com/angular/angular.js/commit/7b6c1d08aceba6704a40302f373400aed9ed0e0b, and originally, a malformed JSON string was forwarded as the data to the http success response handler. This commit adds a specifc test case, even though the behavior is unlikely to break in the future without a change in the $q rejection handling. Related #11433 Closes #15689
2017-02-08 17:41:23 +01:00
fix($http): throw more informative error on invalid JSON response Fixes #15695 Closes #15724
2017-02-19 15:56:17 +05:30
it('should return JSON data with error message if JSON is invalid', function() {
test($http): ensure json deserialization errors are forwarded to error handler Since https://github.com/angular/angular.js/commit/e13eeabd7e34a78becec06cfbe72c23f2dcb85f9, errors thrown from onFulfilled and onRejected handlers are passed to the regular http error handlers. Before this, JSON deserialization errors lead to hard application errors, and could not be handled by application code. This behavior was introduced in https://github.com/angular/angular.js/commit/7b6c1d08aceba6704a40302f373400aed9ed0e0b, and originally, a malformed JSON string was forwarded as the data to the http success response handler. This commit adds a specifc test case, even though the behavior is unlikely to break in the future without a change in the $q rejection handling. Related #11433 Closes #15689
2017-02-08 17:41:23 +01:00
var errCallback = jasmine.createSpy('error');
fix($http): throw more informative error on invalid JSON response Fixes #15695 Closes #15724
2017-02-19 15:56:17 +05:30
$httpBackend.expect('GET', '/url').respond('{abcd}', {'Content-Type': 'application/json'});
$http.get('/url').then(callback).catch(errCallback);
test($http): ensure json deserialization errors are forwarded to error handler Since https://github.com/angular/angular.js/commit/e13eeabd7e34a78becec06cfbe72c23f2dcb85f9, errors thrown from onFulfilled and onRejected handlers are passed to the regular http error handlers. Before this, JSON deserialization errors lead to hard application errors, and could not be handled by application code. This behavior was introduced in https://github.com/angular/angular.js/commit/7b6c1d08aceba6704a40302f373400aed9ed0e0b, and originally, a malformed JSON string was forwarded as the data to the http success response handler. This commit adds a specifc test case, even though the behavior is unlikely to break in the future without a change in the $q rejection handling. Related #11433 Closes #15689
2017-02-08 17:41:23 +01:00
$httpBackend.flush();
expect(callback).not.toHaveBeenCalled();
expect(errCallback).toHaveBeenCalledOnce();
fix($http): throw more informative error on invalid JSON response Fixes #15695 Closes #15724
2017-02-19 15:56:17 +05:30
expect(errCallback.calls.mostRecent().args[0]).toEqualMinErr('$http', 'baddata');
test($http): ensure json deserialization errors are forwarded to error handler Since https://github.com/angular/angular.js/commit/e13eeabd7e34a78becec06cfbe72c23f2dcb85f9, errors thrown from onFulfilled and onRejected handlers are passed to the regular http error handlers. Before this, JSON deserialization errors lead to hard application errors, and could not be handled by application code. This behavior was introduced in https://github.com/angular/angular.js/commit/7b6c1d08aceba6704a40302f373400aed9ed0e0b, and originally, a malformed JSON string was forwarded as the data to the http success response handler. This commit adds a specifc test case, even though the behavior is unlikely to break in the future without a change in the $q rejection handling. Related #11433 Closes #15689
2017-02-08 17:41:23 +01:00
});
fix($http): do not throw error if `Content-Type` is not `application/json` but response is JSON-like Previously, when the response data was JSON-like, `$http` would try to `JSON.parse` them and throw if they were not actually JSON. This happened even if the `Content-Type` header was not `application/json`. As a result, it was not possible to send `text/plain` data that looked like JSON (e.g. `{abcd}`). The reason for not relying solely on the `Content-Type` is that many users serve JSON data without proper headers. This commit fixes it by returning the raw response text if `$http` fails to parse a JSON-like response, unless the `Content-Type` header has been explicitly set to `application/json` (in which case it will still fail with an error). Fixes #16027 Closes #16075
2017-06-29 14:30:53 +03:00
it('should not throw an error if JSON is invalid but content-type is not application/json', function() {
$httpBackend.expect('GET', '/url').respond('{abcd}', {'Content-Type': 'text/plain'});
$http.get('/url').then(callback);
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
});
it('should not throw an error if JSON is invalid but content-type is not specified', function() {
$httpBackend.expect('GET', '/url').respond('{abcd}');
$http.get('/url').then(callback);
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
});
fix($http): allow multiple json vulnerability prefixes We strip out both: )]}', )]}'
2011-10-18 17:03:48 -07:00
fix($http): do not throw error if `Content-Type` is not `application/json` but response is JSON-like Previously, when the response data was JSON-like, `$http` would try to `JSON.parse` them and throw if they were not actually JSON. This happened even if the `Content-Type` header was not `application/json`. As a result, it was not possible to send `text/plain` data that looked like JSON (e.g. `{abcd}`). The reason for not relying solely on the `Content-Type` is that many users serve JSON data without proper headers. This commit fixes it by returning the raw response text if `$http` fails to parse a JSON-like response, unless the `Content-Type` header has been explicitly set to `application/json` (in which case it will still fail with an error). Fixes #16027 Closes #16075
2017-06-29 14:30:53 +03:00
it('should return response unprocessed if JSON is invalid but content-type is not application/json', function() {
var response = '{abcd}';
$httpBackend.expect('GET', '/url').respond(response, {'Content-Type': 'text/plain'});
$http.get('/url').then(callback);
$httpBackend.flush();
expect(callback.calls.mostRecent().args[0].data).toBe(response);
});
it('should return response unprocessed if JSON is invalid but content-type is not specified', function() {
var response = '{abcd}';
$httpBackend.expect('GET', '/url').respond(response);
$http.get('/url').then(callback);
$httpBackend.flush();
expect(callback.calls.mostRecent().args[0].data).toBe(response);
});
});
fix($http): allow multiple json vulnerability prefixes We strip out both: )]}', )]}'
2011-10-18 17:03:48 -07:00
feat($http): expose req/resp headers to transform fns
2012-01-04 09:21:05 -08:00
it('should have access to response headers', function() {
$httpBackend.expect('GET', '/url').respond(200, 'response', {h1: 'header1'});
$http.get('/url', {
transformResponse: function(data, headers) {
return headers('h1');
}
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
}).then(callback);
feat($http): expose req/resp headers to transform fns
2012-01-04 09:21:05 -08:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toBe('header1');
feat($http): expose req/resp headers to transform fns
2012-01-04 09:21:05 -08:00
});
feat($http): pass response status code to data transform functions Fixes #10324 Closes #6734 Closes #10440
2014-12-12 19:04:47 +01:00
it('should have access to response status', function() {
$httpBackend.expect('GET', '/url').respond(200, 'response', {h1: 'header1'});
$http.get('/url', {
transformResponse: function(data, headers, status) {
return status;
}
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
}).then(callback);
feat($http): pass response status code to data transform functions Fixes #10324 Closes #6734 Closes #10440
2014-12-12 19:04:47 +01:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toBe(200);
feat($http): pass response status code to data transform functions Fixes #10324 Closes #6734 Closes #10440
2014-12-12 19:04:47 +01:00
});
feat($http): expose req/resp headers to transform fns
2012-01-04 09:21:05 -08:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should pipeline more functions', function() {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
function first(d, h) {return d + '-first:' + h('h1');}
chore(jshint): enforce jshint for tests Closes #7264
2014-04-26 23:07:28 +03:00
function second(d) {return uppercase(d);}
fix($http): default json transformation should not crash on angular template The way we determine whether it's json is lame anyway. We need to change that. We should probably check the content type header...
2011-11-04 18:02:47 -07:00
feat($http): expose req/resp headers to transform fns
2012-01-04 09:21:05 -08:00
$httpBackend.expect('POST', '/url').respond(200, 'resp', {h1: 'v1'});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http.post('/url', '', {transformResponse: [first, second]}).then(callback);
fix($http): default json transformation should not crash on angular template The way we determine whether it's json is lame anyway. We need to change that. We should probably check the content type header...
2011-11-04 18:02:47 -07:00
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toBe('RESP-FIRST:V1');
fix($http): default json transformation should not crash on angular template The way we determine whether it's json is lame anyway. We need to change that. We should probably check the content type header...
2011-11-04 18:02:47 -07:00
});
fix($http): apply `transformResponse` even when `data` is empty Note, that (as a by-product of the previous implementation) only non-empty data was passed through the `transformResponse` pipeline. This is no longer the case. When using a custom `transformResponse` function, one should make sure it can also handle an empty (i.e. falsy) `data` argument appropriately. Fixes #12976 Closes #12979
2015-09-30 16:56:48 +03:00
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
it('should apply `transformResponse` even if the response data is empty', function() {
fix($http): apply `transformResponse` even when `data` is empty Note, that (as a by-product of the previous implementation) only non-empty data was passed through the `transformResponse` pipeline. This is no longer the case. When using a custom `transformResponse` function, one should make sure it can also handle an empty (i.e. falsy) `data` argument appropriately. Fixes #12976 Closes #12979
2015-09-30 16:56:48 +03:00
var callback = jasmine.createSpy('transformResponse');
var config = {transformResponse: callback};
$httpBackend.expect('GET', '/url1').respond(200, undefined);
$httpBackend.expect('GET', '/url2').respond(200, null);
$httpBackend.expect('GET', '/url3').respond(200, '');
$http.get('/url1', config);
$http.get('/url2', config);
$http.get('/url3', config);
$httpBackend.flush();
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
expect(callback).toHaveBeenCalledTimes(3);
expect(callback.calls.argsFor(0)[0]).toBeUndefined();
expect(callback.calls.argsFor(1)[0]).toBe(null);
expect(callback.calls.argsFor(2)[0]).toBe('');
fix($http): apply `transformResponse` even when `data` is empty Note, that (as a by-product of the previous implementation) only non-empty data was passed through the `transformResponse` pipeline. This is no longer the case. When using a custom `transformResponse` function, one should make sure it can also handle an empty (i.e. falsy) `data` argument appropriately. Fixes #12976 Closes #12979
2015-09-30 16:56:48 +03:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
describe('cache', function() {
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
var cache;
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
beforeEach(inject(function($cacheFactory) {
cache = $cacheFactory('testCache');
}));
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
function doFirstCacheRequest(method, respStatus, headers) {
$httpBackend.expect(method || 'GET', '/url').respond(respStatus || 200, 'content', headers);
feat($q): report promises with non rejection callback Rejected promises that do not have a callback to handle the rejection report this to $exceptionHandler so they can be logged to the console. BREAKING CHANGE Unhandled rejected promises will be logged to $exceptionHandler. Tests that depend on specific order or number of messages in $exceptionHandler will need to handle rejected promises report. Closes: #13653 Closes: #7992
2016-01-01 23:40:00 +01:00
$http({method: method || 'GET', url: '/url', cache: cache}).catch(noop);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
}
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
it('should cache GET request when cache is provided', inject(function($rootScope) {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
doFirstCacheRequest();
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'get', url: '/url', cache: cache}).then(callback);
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
$rootScope.$digest();
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toBe('content');
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
}));
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat(http): allow caching for JSONP requests Closes #1947 Closes #8356
2014-07-26 23:29:59 +03:00
it('should cache JSONP request when cache is provided', inject(function($rootScope) {
feat($http): JSONP callback must be specified by `jsonpCallbackParam` config The query parameter that will be used to transmit the JSONP callback to the server is now specified via the `jsonpCallbackParam` config value, instead of using the `JSON_CALLBACK` placeholder. * Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error. * Any request that provides a parameter with the same name as that given by the `jsonpCallbackParam` config property will cause an error. This is to prevent malicious attack via the response from an app inadvertently allowing untrusted data to be used to generate the callback parameter. Closes #15161 Closes #15143 Closes #11352 Closes #11328 BREAKING CHANGE You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the `jsonpCallbackParam` property of the config object, or app-wide via the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default. Before this change: ``` $http.json('trusted/url?callback=JSON_CALLBACK'); $http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'}); ``` After this change: ``` $http.json('trusted/url'); $http.json('other/trusted/url', {callbackParam:'cb'}); ```
2016-10-04 14:18:41 +01:00
$httpBackend.expect('JSONP', '/url?callback=JSON_CALLBACK').respond('content');
$http({method: 'JSONP', url: $sce.trustAsResourceUrl('/url'), cache: cache});
feat(http): allow caching for JSONP requests Closes #1947 Closes #8356
2014-07-26 23:29:59 +03:00
$httpBackend.flush();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'JSONP', url: $sce.trustAsResourceUrl('/url'), cache: cache}).then(callback);
feat(http): allow caching for JSONP requests Closes #1947 Closes #8356
2014-07-26 23:29:59 +03:00
$rootScope.$digest();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toBe('content');
feat(http): allow caching for JSONP requests Closes #1947 Closes #8356
2014-07-26 23:29:59 +03:00
}));
style(*): add rule disallowSpacesInAnonymousFunctionExpression beforeOpeningRoundBrace, including i18n generator
2014-10-22 17:31:27 -04:00
it('should cache request when cache is provided and no method specified', function() {
fix($http): send GET requests by default Fixes #5985 Closes #6401
2014-02-21 22:24:27 +01:00
doFirstCacheRequest();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({url: '/url', cache: cache}).then(callback);
fix($http): send GET requests by default Fixes #5985 Closes #6401
2014-02-21 22:24:27 +01:00
$rootScope.$digest();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toBe('content');
fix($http): send GET requests by default Fixes #5985 Closes #6401
2014-02-21 22:24:27 +01:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should not cache when cache is not provided', function() {
doFirstCacheRequest();
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.expect('GET', '/url').respond();
$http({method: 'GET', url: '/url'});
});
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should perform request when cache cleared', function() {
doFirstCacheRequest();
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
cache.removeAll();
$httpBackend.expect('GET', '/url').respond();
$http({method: 'GET', url: '/url', cache: cache});
});
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should always call callback asynchronously', function() {
doFirstCacheRequest();
$http({method: 'get', url: '/url', cache: cache}).then(callback);
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).not.toHaveBeenCalled();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should not cache POST request', function() {
doFirstCacheRequest('POST');
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.expect('POST', '/url').respond('content2');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'POST', url: '/url', cache: cache}).then(callback);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
feat(mocks.$httpBackend): add $httpBackend mock $httpBackend mock allows: - expecting (asserting) requests - stubbing (responding without asserting) Add empty $httpBackend service (currently just wrapper for $browser.xhr)
2011-08-16 21:24:53 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toBe('content2');
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should not cache PUT request', function() {
doFirstCacheRequest('PUT');
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.expect('PUT', '/url').respond('content2');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'PUT', url: '/url', cache: cache}).then(callback);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
feat(mocks.$httpBackend): add $httpBackend mock $httpBackend mock allows: - expecting (asserting) requests - stubbing (responding without asserting) Add empty $httpBackend service (currently just wrapper for $browser.xhr)
2011-08-16 21:24:53 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toBe('content2');
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should not cache DELETE request', function() {
doFirstCacheRequest('DELETE');
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.expect('DELETE', '/url').respond(206);
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'DELETE', url: '/url', cache: cache}).then(callback);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
feat(mocks.$httpBackend): add $httpBackend mock $httpBackend mock allows: - expecting (asserting) requests - stubbing (responding without asserting) Add empty $httpBackend service (currently just wrapper for $browser.xhr)
2011-08-16 21:24:53 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should not cache non 2xx responses', function() {
doFirstCacheRequest('GET', 404);
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.expect('GET', '/url').respond('content2');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url', cache: cache}).then(callback);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
feat(mocks.$httpBackend): add $httpBackend mock $httpBackend mock allows: - expecting (asserting) requests - stubbing (responding without asserting) Add empty $httpBackend service (currently just wrapper for $browser.xhr)
2011-08-16 21:24:53 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toBe('content2');
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
it('should cache the headers as well', inject(function($rootScope) {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
doFirstCacheRequest('GET', 200, {'content-encoding': 'gzip', 'server': 'Apache'});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
callback.and.callFake(function(response) {
expect(response.headers()).toEqual(extend(Object.create(null), {
'content-encoding': 'gzip',
'server': 'Apache'
}));
expect(response.headers('server')).toBe('Apache');
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url', cache: cache}).then(callback);
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
$rootScope.$digest();
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
}));
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
it('should not share the cached headers object instance', inject(function($rootScope) {
doFirstCacheRequest('GET', 200, {'content-encoding': 'gzip', 'server': 'Apache'});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
callback.and.callFake(function(response) {
expect(response.headers()).toEqual(cache.get('/url')[2]);
expect(response.headers()).not.toBe(cache.get('/url')[2]);
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url', cache: cache}).then(callback);
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
$rootScope.$digest();
expect(callback).toHaveBeenCalledOnce();
}));
fix(http): preserve config object when resolving from cache Fixes #9004 Closes #9030
2014-09-11 15:02:30 +03:00
it('should not share the pending cached headers object instance', inject(function($rootScope) {
var firstResult;
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
callback.and.callFake(function(result) {
fix(http): preserve config object when resolving from cache Fixes #9004 Closes #9030
2014-09-11 15:02:30 +03:00
expect(result.headers()).toEqual(firstResult.headers());
expect(result.headers()).not.toBe(firstResult.headers());
});
$httpBackend.expect('GET', '/url').respond(200, 'content', {'content-encoding': 'gzip', 'server': 'Apache'});
$http({method: 'GET', url: '/url', cache: cache}).then(function(result) {
firstResult = result;
});
$http({method: 'GET', url: '/url', cache: cache}).then(callback);
$httpBackend.flush();
expect(callback).toHaveBeenCalledOnce();
}));
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
it('should cache status code as well', inject(function($rootScope) {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
doFirstCacheRequest('GET', 201);
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
callback.and.callFake(function(response) {
expect(response.status).toBe(201);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'get', url: '/url', cache: cache}).then(callback);
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
$rootScope.$digest();
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect(callback).toHaveBeenCalledOnce();
}));
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
feat($http): allow differentiation between XHR completion, error, abort, timeout Previously, it wasn't possible to tell if an `$http`-initiated XMLHttpRequest was completed normally or with an error or it was aborted or timed out. This commit adds a new property on the `response` object (`xhrStatus`) which allows to defferentiate between the possible statuses. Fixes #15924 Closes #15847
2017-02-21 23:42:16 +01:00
it('should cache xhrStatus as well', inject(function($rootScope) {
doFirstCacheRequest('GET', 201, null);
callback.and.callFake(function(response) {
expect(response.xhrStatus).toBe('complete');
});
$http({method: 'get', url: '/url', cache: cache}).then(callback);
$rootScope.$digest();
expect(callback).toHaveBeenCalledOnce();
}));
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
it('should use cache even if second request was made before the first returned', function() {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.expect('GET', '/url').respond(201, 'fake-response');
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
callback.and.callFake(function(response) {
expect(response.data).toBe('fake-response');
expect(response.status).toBe(201);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/url', cache: cache}).then(callback);
$http({method: 'GET', url: '/url', cache: cache}).then(callback);
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
expect(callback).toHaveBeenCalled();
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
expect(callback).toHaveBeenCalledTimes(2);
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
});
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
fix(http): preserve config object when resolving from cache Fixes #9004 Closes #9030
2014-09-11 15:02:30 +03:00
it('should preserve config object when resolving from cache', function() {
$httpBackend.expect('GET', '/url').respond(200, 'content');
$http({method: 'GET', url: '/url', cache: cache, headers: {foo: 'bar'}});
$httpBackend.flush();
$http({method: 'GET', url: '/url', cache: cache, headers: {foo: 'baz'}}).then(callback);
$rootScope.$digest();
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
expect(callback.calls.mostRecent().args[0].config.headers.foo).toBe('baz');
fix(http): preserve config object when resolving from cache Fixes #9004 Closes #9030
2014-09-11 15:02:30 +03:00
});
it('should preserve config object when resolving from pending cache', function() {
$httpBackend.expect('GET', '/url').respond(200, 'content');
$http({method: 'GET', url: '/url', cache: cache, headers: {foo: 'bar'}});
$http({method: 'GET', url: '/url', cache: cache, headers: {foo: 'baz'}}).then(callback);
$httpBackend.flush();
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
expect(callback.calls.mostRecent().args[0].config.headers.foo).toBe('baz');
fix(http): preserve config object when resolving from cache Fixes #9004 Closes #9030
2014-09-11 15:02:30 +03:00
});
it('should preserve config object when rejecting from pending cache', function() {
$httpBackend.expect('GET', '/url').respond(404, 'content');
feat($q): report promises with non rejection callback Rejected promises that do not have a callback to handle the rejection report this to $exceptionHandler so they can be logged to the console. BREAKING CHANGE Unhandled rejected promises will be logged to $exceptionHandler. Tests that depend on specific order or number of messages in $exceptionHandler will need to handle rejected promises report. Closes: #13653 Closes: #7992
2016-01-01 23:40:00 +01:00
$http({method: 'GET', url: '/url', cache: cache, headers: {foo: 'bar'}}).catch(noop);
fix(http): preserve config object when resolving from cache Fixes #9004 Closes #9030
2014-09-11 15:02:30 +03:00
$http({method: 'GET', url: '/url', cache: cache, headers: {foo: 'baz'}}).catch(callback);
$httpBackend.flush();
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
expect(callback.calls.mostRecent().args[0].config.headers.foo).toBe('baz');
fix(http): preserve config object when resolving from cache Fixes #9004 Closes #9030
2014-09-11 15:02:30 +03:00
});
style(*): add rule disallowSpacesInAnonymousFunctionExpression beforeOpeningRoundBrace, including i18n generator
2014-10-22 17:31:27 -04:00
it('should allow the cached value to be an empty string', function() {
fix($http): allow empty responses to be cached Closes #3809
2013-08-29 18:52:30 -07:00
cache.put('/abc', '');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
callback.and.callFake(function(response) {
expect(response.data).toBe('');
expect(response.status).toBe(200);
fix($http): allow empty responses to be cached Closes #3809
2013-08-29 18:52:30 -07:00
});
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'GET', url: '/abc', cache: cache}).then(callback);
fix($http): allow empty responses to be cached Closes #3809
2013-08-29 18:52:30 -07:00
$rootScope.$digest();
expect(callback).toHaveBeenCalled();
});
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
it('should default to status code 200 and empty headers if cache contains a non-array element',
inject(function($rootScope) {
cache.put('/myurl', 'simple response');
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http.get('/myurl', {cache: cache}).then(function(response) {
expect(response.data).toBe('simple response');
expect(response.status).toBe(200);
expect(response.headers()).toEqual(Object.create(null));
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
callback();
});
$rootScope.$digest();
expect(callback).toHaveBeenCalledOnce();
})
);
feat(http): set custom default cache in $http.defaults.cache When we need more control over http caching, we may want to provide a custom cache to be used in all http requests by default. To skip default cache, set {cache: false} in request configuration. To use other cache, set {cache: cache} as before. See #2079
2013-02-28 09:25:21 +04:00
style(*): add rule disallowSpacesInAnonymousFunctionExpression beforeOpeningRoundBrace, including i18n generator
2014-10-22 17:31:27 -04:00
describe('$http.defaults.cache', function() {
feat(http): set custom default cache in $http.defaults.cache When we need more control over http caching, we may want to provide a custom cache to be used in all http requests by default. To skip default cache, set {cache: false} in request configuration. To use other cache, set {cache: cache} as before. See #2079
2013-02-28 09:25:21 +04:00
it('should be undefined by default', function() {
chore(jshint): enforce jshint for tests Closes #7264
2014-04-26 23:07:28 +03:00
expect($http.defaults.cache).toBeUndefined();
feat(http): set custom default cache in $http.defaults.cache When we need more control over http caching, we may want to provide a custom cache to be used in all http requests by default. To skip default cache, set {cache: false} in request configuration. To use other cache, set {cache: cache} as before. See #2079
2013-02-28 09:25:21 +04:00
});
it('should cache requests when no cache given in request config', function() {
$http.defaults.cache = cache;
// First request fills the cache from server response.
$httpBackend.expect('GET', '/url').respond(200, 'content');
$http({method: 'GET', url: '/url'}); // Notice no cache given in config.
$httpBackend.flush();
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
// Second should be served from cache, without sending request to server.
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'get', url: '/url'}).then(callback);
feat(http): set custom default cache in $http.defaults.cache When we need more control over http caching, we may want to provide a custom cache to be used in all http requests by default. To skip default cache, set {cache: false} in request configuration. To use other cache, set {cache: cache} as before. See #2079
2013-02-28 09:25:21 +04:00
$rootScope.$digest();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toBe('content');
feat(http): set custom default cache in $http.defaults.cache When we need more control over http caching, we may want to provide a custom cache to be used in all http requests by default. To skip default cache, set {cache: false} in request configuration. To use other cache, set {cache: cache} as before. See #2079
2013-02-28 09:25:21 +04:00
// Invalidate cache entry.
chore(eslint): enable `quotes: ["error", "single"]` The quotes rule had to be disabled for e2e tests generated from ngdoc because dgeni templates use double quotes as string delimiters. Since we can't have guarantees that dgeni template wrappers will follow the same JS code style the Angular 1 repo uses, we should find a way to enforce our ESLint setup only for the parts in this repo, perhaps via prepending a generated `/* eslint-enable OUR_RULES */` pragma. Closes #15011
2016-08-10 12:13:14 +02:00
$http.defaults.cache.remove('/url');
feat(http): set custom default cache in $http.defaults.cache When we need more control over http caching, we may want to provide a custom cache to be used in all http requests by default. To skip default cache, set {cache: false} in request configuration. To use other cache, set {cache: cache} as before. See #2079
2013-02-28 09:25:21 +04:00
// After cache entry removed, a request should be sent to server.
$httpBackend.expect('GET', '/url').respond(200, 'content');
$http({method: 'GET', url: '/url'});
$httpBackend.flush();
});
it('should have less priority than explicitly given cache', inject(function($cacheFactory) {
var localCache = $cacheFactory('localCache');
$http.defaults.cache = cache;
// Fill local cache.
$httpBackend.expect('GET', '/url').respond(200, 'content-local-cache');
$http({method: 'GET', url: '/url', cache: localCache});
$httpBackend.flush();
// Fill default cache.
$httpBackend.expect('GET', '/url').respond(200, 'content-default-cache');
$http({method: 'GET', url: '/url'});
$httpBackend.flush();
// Serve request from default cache when no local given.
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'get', url: '/url'}).then(callback);
feat(http): set custom default cache in $http.defaults.cache When we need more control over http caching, we may want to provide a custom cache to be used in all http requests by default. To skip default cache, set {cache: false} in request configuration. To use other cache, set {cache: cache} as before. See #2079
2013-02-28 09:25:21 +04:00
$rootScope.$digest();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toBe('content-default-cache');
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
callback.calls.reset();
feat(http): set custom default cache in $http.defaults.cache When we need more control over http caching, we may want to provide a custom cache to be used in all http requests by default. To skip default cache, set {cache: false} in request configuration. To use other cache, set {cache: cache} as before. See #2079
2013-02-28 09:25:21 +04:00
// Serve request from local cache when it is given (but default filled too).
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'get', url: '/url', cache: localCache}).then(callback);
feat(http): set custom default cache in $http.defaults.cache When we need more control over http caching, we may want to provide a custom cache to be used in all http requests by default. To skip default cache, set {cache: false} in request configuration. To use other cache, set {cache: cache} as before. See #2079
2013-02-28 09:25:21 +04:00
$rootScope.$digest();
expect(callback).toHaveBeenCalledOnce();
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
expect(callback.calls.mostRecent().args[0].data).toBe('content-local-cache');
feat(http): set custom default cache in $http.defaults.cache When we need more control over http caching, we may want to provide a custom cache to be used in all http requests by default. To skip default cache, set {cache: false} in request configuration. To use other cache, set {cache: cache} as before. See #2079
2013-02-28 09:25:21 +04:00
}));
it('should be skipped if {cache: false} is passed in request config', function() {
$http.defaults.cache = cache;
$httpBackend.expect('GET', '/url').respond(200, 'content');
$http({method: 'GET', url: '/url'});
$httpBackend.flush();
$httpBackend.expect('GET', '/url').respond();
$http({method: 'GET', url: '/url', cache: false});
$httpBackend.flush();
});
});
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): add support for aborting via timeout promises If the timeout argument is a promise, abort the request when it is resolved. Implemented by adding support to $httpBackend service and $httpBackend mock service. This api can also be used to explicitly abort requests while keeping the communication between the deffered and promise unidirectional. Closes #1159
2013-04-27 11:22:03 -04:00
describe('timeout', function() {
it('should abort requests when timeout promise resolves', inject(function($q) {
var canceler = $q.defer();
$httpBackend.expect('GET', '/some').respond(200);
test($http): remove use of deprecated `success` and `error` calls in tests
2015-09-07 14:43:33 +01:00
$http({method: 'GET', url: '/some', timeout: canceler.promise}).catch(
function(response) {
expect(response.data).toBeUndefined();
expect(response.status).toBe(-1);
fix($http): set correct xhrStatus in response when using 'timeout' This correctly sets "timeout" if a request fails because the timeout (numerical or $timeout) is exceeded, and "abort" if the request is aborted by resolving a promise that was passed in.
2017-10-08 21:48:06 +02:00
expect(response.xhrStatus).toBe('abort');
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
expect(response.headers()).toEqual(Object.create(null));
test($http): remove use of deprecated `success` and `error` calls in tests
2015-09-07 14:43:33 +01:00
expect(response.config.url).toBe('/some');
feat($http): add support for aborting via timeout promises If the timeout argument is a promise, abort the request when it is resolved. Implemented by adding support to $httpBackend service and $httpBackend mock service. This api can also be used to explicitly abort requests while keeping the communication between the deffered and promise unidirectional. Closes #1159
2013-04-27 11:22:03 -04:00
callback();
});
$rootScope.$apply(function() {
canceler.resolve();
});
expect(callback).toHaveBeenCalled();
$httpBackend.verifyNoOutstandingExpectation();
$httpBackend.verifyNoOutstandingRequest();
}));
test($http): test that timed out $http request rejects promise Closes #7688 Closes #7686
2014-06-03 21:30:48 -04:00
fix($http): set correct xhrStatus in response when using 'timeout' This correctly sets "timeout" if a request fails because the timeout (numerical or $timeout) is exceeded, and "abort" if the request is aborted by resolving a promise that was passed in.
2017-10-08 21:48:06 +02:00
it('should timeout request when numerical timeout is exceeded', inject(function($timeout) {
var onFulfilled = jasmine.createSpy('onFulfilled');
var onRejected = jasmine.createSpy('onRejected').and.callFake(function(response) {
expect(response.xhrStatus).toBe('timeout');
});
$httpBackend.expect('GET', '/some').respond(200);
$http({
method: 'GET',
url: '/some',
timeout: 10
}).then(onFulfilled, onRejected);
$timeout.flush(100);
expect(onFulfilled).not.toHaveBeenCalled();
expect(onRejected).toHaveBeenCalled();
}));
test($http): test that timed out $http request rejects promise Closes #7688 Closes #7686
2014-06-03 21:30:48 -04:00
it('should reject promise when timeout promise resolves', inject(function($timeout) {
var onFulfilled = jasmine.createSpy('onFulfilled');
fix($http): set correct xhrStatus in response when using 'timeout' This correctly sets "timeout" if a request fails because the timeout (numerical or $timeout) is exceeded, and "abort" if the request is aborted by resolving a promise that was passed in.
2017-10-08 21:48:06 +02:00
var onRejected = jasmine.createSpy('onRejected').and.callFake(function(response) {
expect(response.xhrStatus).toBe('timeout');
});
test($http): test that timed out $http request rejects promise Closes #7688 Closes #7686
2014-06-03 21:30:48 -04:00
$httpBackend.expect('GET', '/some').respond(200);
fix($http): set correct xhrStatus in response when using 'timeout' This correctly sets "timeout" if a request fails because the timeout (numerical or $timeout) is exceeded, and "abort" if the request is aborted by resolving a promise that was passed in.
2017-10-08 21:48:06 +02:00
$http({
method: 'GET',
url: '/some',
timeout: $timeout(noop, 10)
}).then(onFulfilled, onRejected);
test($http): test that timed out $http request rejects promise Closes #7688 Closes #7686
2014-06-03 21:30:48 -04:00
$timeout.flush(100);
expect(onFulfilled).not.toHaveBeenCalled();
fix($http): set correct xhrStatus in response when using 'timeout' This correctly sets "timeout" if a request fails because the timeout (numerical or $timeout) is exceeded, and "abort" if the request is aborted by resolving a promise that was passed in.
2017-10-08 21:48:06 +02:00
expect(onRejected).toHaveBeenCalled();
test($http): test that timed out $http request rejects promise Closes #7688 Closes #7686
2014-06-03 21:30:48 -04:00
}));
feat($http): add support for aborting via timeout promises If the timeout argument is a promise, abort the request when it is resolved. Implemented by adding support to $httpBackend service and $httpBackend mock service. This api can also be used to explicitly abort requests while keeping the communication between the deffered and promise unidirectional. Closes #1159
2013-04-27 11:22:03 -04:00
});
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
describe('pendingRequests', function() {
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should be an array of pending requests', function() {
$httpBackend.when('GET').respond(200);
expect($http.pendingRequests.length).toBe(0);
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$http({method: 'get', url: '/some'});
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
$rootScope.$digest();
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect($http.pendingRequests.length).toBe(1);
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
expect($http.pendingRequests.length).toBe(0);
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
it('should update pending requests even when served from cache', inject(function($rootScope) {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.when('GET').respond(200);
feat(mocks.$httpBackend): add $httpBackend mock $httpBackend mock allows: - expecting (asserting) requests - stubbing (responding without asserting) Add empty $httpBackend service (currently just wrapper for $browser.xhr)
2011-08-16 21:24:53 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$http({method: 'get', url: '/cached', cache: true});
$http({method: 'get', url: '/cached', cache: true});
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
$rootScope.$digest();
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect($http.pendingRequests.length).toBe(2);
feat($http): allow passing custom cache instance per request You can still use cache: true, which will use $http's default cache.
2011-11-04 16:34:47 -07:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$httpBackend.flush();
expect($http.pendingRequests.length).toBe(0);
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
$http({method: 'get', url: '/cached', cache: true});
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
spyOn($http.pendingRequests, 'push').and.callThrough();
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
$rootScope.$digest();
expect($http.pendingRequests.push).toHaveBeenCalledOnce();
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
fix($http): fix and cleanup $http and friends $http: - use promises internally - get rid of XhrFuture that was previously used internally - get rid of $browser.defer calls for async stuff (serving from cache), promises will take care of asynchronicity - fix transformation bugs (when caching requested + multiple request pending + error is returned) - get rid of native header parsing and instead just lazily parse the header string $httpBackend: - don't return raw/mock XMLHttpRequest object (we don't use it for anything anymore) - call the callback with response headers string mock $httpBackend: - unify response api for expect and when - call the callback with response headers string - changed the expect/when failure error message so that EXPECTED and GOT values are aligned Conflicts: src/service/http.js test/service/compilerSpec.js test/service/httpSpec.js
2011-12-28 09:26:22 -08:00
$rootScope.$apply();
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect($http.pendingRequests.length).toBe(0);
}));
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
it('should remove the request before firing callbacks', function() {
$httpBackend.when('GET').respond(200);
feat($http): remove deprecated callback methods: `success()/error()` Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
2016-09-19 18:26:25 +03:00
$http({method: 'get', url: '/url'}).then(function() {
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect($http.pendingRequests.length).toBe(0);
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
$rootScope.$digest();
feat($http): allow interceptors to be services
2011-12-01 18:54:46 -05:00
expect($http.pendingRequests.length).toBe(1);
$httpBackend.flush();
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
feat($http): expose the defaults config as $http.defaults Often it is impossible to set the http defaults during the config phase, because the config info is not available at this time. A good example is authentication - often the app needs to bootstrap, allow user to enter credentials and only then it gains access to session token which then should be sent to the server with every request. Without having the ability to set the defaults at runtime, the developer either has to resort to hacks, or has to set the session token header with every request made by the app.
2012-04-10 23:20:53 -07:00
describe('defaults', function() {
it('should expose the defaults object at runtime', function() {
expect($http.defaults).toBeDefined();
$http.defaults.headers.common.foo = 'bar';
$httpBackend.expect('GET', '/url', undefined, function(headers) {
chore(*): switch from JSHint/JSCS to ESLint Thanks to @narretz for help in fixing style violations and to @gkalpak for a very extensive review. Closes #14952
2016-07-20 15:45:04 +02:00
return headers['foo'] === 'bar';
feat($http): expose the defaults config as $http.defaults Often it is impossible to set the http defaults during the config phase, because the config info is not available at this time. A good example is authentication - often the app needs to bootstrap, allow user to enter credentials and only then it gains access to session token which then should be sent to the server with every request. Without having the ability to set the defaults at runtime, the developer either has to resort to hacks, or has to set the session token header with every request made by the app.
2012-04-10 23:20:53 -07:00
}).respond('');
$http.get('/url');
$httpBackend.flush();
});
fix($http): ensure default headers PUT and POST are different objects Send PUT and POST through copy() to make sure they are not the same. Closes #5742 Closes #5747 Closes #5764
2014-01-11 15:20:54 -08:00
feat($http): support custom params serializers Closes #3740 Closes #7429 Closes #9224 Closes #11461
2015-03-30 15:37:04 +02:00
it('should have separate objects for defaults PUT and POST', function() {
fix($http): ensure default headers PUT and POST are different objects Send PUT and POST through copy() to make sure they are not the same. Closes #5742 Closes #5747 Closes #5764
2014-01-11 15:20:54 -08:00
expect($http.defaults.headers.post).not.toBe($http.defaults.headers.put);
expect($http.defaults.headers.post).not.toBe($http.defaults.headers.patch);
expect($http.defaults.headers.put).not.toBe($http.defaults.headers.patch);
chore(jshint): enforce jshint for tests Closes #7264
2014-04-26 23:07:28 +03:00
});
feat($http): support custom params serializers Closes #3740 Closes #7429 Closes #9224 Closes #11461
2015-03-30 15:37:04 +02:00
it('should expose default param serializer at runtime', function() {
var paramSerializer = $http.defaults.paramSerializer;
expect(paramSerializer({foo: 'foo', bar: ['bar', 'baz']})).toEqual('bar=bar&bar=baz&foo=foo');
});
feat($http): expose the defaults config as $http.defaults Often it is impossible to set the http defaults during the config phase, because the config info is not available at this time. A good example is authentication - often the app needs to bootstrap, allow user to enter credentials and only then it gains access to session token which then should be sent to the server with every request. Without having the ability to set the defaults at runtime, the developer either has to resort to hacks, or has to set the session token header with every request made by the app.
2012-04-10 23:20:53 -07:00
});
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
});
fix($http): properly increment/decrement `$browser.outstandingRequestCount` Calling `$http` will not increment `$browser.outstandingRequestCount` until after all (potentially) asynchronous request interceptors have been processed and will decrement it before any (potentially) asynchronous response interceptors have been processed. This can lead to `$browser.notifyWhenNoOutstandingRequests` firing prematurely, which can be problematic in end-to-end tests. This commit fixes this, by synchronizing the increment/decrement operations with `$http`'s internal interceptor promise chain. Fixes #13782 Closes #13862 Closes #14921 BREAKING CHANGE: HTTP requests now update the outstanding request count synchronously. Previously the request count would not have been updated until the request to the server is actually in flight. Now the request count is updated before the async interceptor is called. The new behaviour is correct but it may change the expected behaviour in a small number of e2e test cases where an async request interceptor is being used.
2016-01-27 17:44:47 -06:00
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
describe('$browser\'s outstandingRequestCount', function() {
var $http;
var $httpBackend;
var $rootScope;
var incOutstandingRequestCountSpy;
var completeOutstandingRequestSpy;
fix($http): properly increment/decrement `$browser.outstandingRequestCount` Calling `$http` will not increment `$browser.outstandingRequestCount` until after all (potentially) asynchronous request interceptors have been processed and will decrement it before any (potentially) asynchronous response interceptors have been processed. This can lead to `$browser.notifyWhenNoOutstandingRequests` firing prematurely, which can be problematic in end-to-end tests. This commit fixes this, by synchronizing the increment/decrement operations with `$http`'s internal interceptor promise chain. Fixes #13782 Closes #13862 Closes #14921 BREAKING CHANGE: HTTP requests now update the outstanding request count synchronously. Previously the request count would not have been updated until the request to the server is actually in flight. Now the request count is updated before the async interceptor is called. The new behaviour is correct but it may change the expected behaviour in a small number of e2e test cases where an async request interceptor is being used.
2016-01-27 17:44:47 -06:00
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
describe('without interceptors', function() {
beforeEach(setupServicesAndSpies);
it('should immediately call `$browser.$$incOutstandingRequestCount()`', function() {
fix($http): properly increment/decrement `$browser.outstandingRequestCount` Calling `$http` will not increment `$browser.outstandingRequestCount` until after all (potentially) asynchronous request interceptors have been processed and will decrement it before any (potentially) asynchronous response interceptors have been processed. This can lead to `$browser.notifyWhenNoOutstandingRequests` firing prematurely, which can be problematic in end-to-end tests. This commit fixes this, by synchronizing the increment/decrement operations with `$http`'s internal interceptor promise chain. Fixes #13782 Closes #13862 Closes #14921 BREAKING CHANGE: HTTP requests now update the outstanding request count synchronously. Previously the request count would not have been updated until the request to the server is actually in flight. Now the request count is updated before the async interceptor is called. The new behaviour is correct but it may change the expected behaviour in a small number of e2e test cases where an async request interceptor is being used.
2016-01-27 17:44:47 -06:00
expect(incOutstandingRequestCountSpy).not.toHaveBeenCalled();
$http.get('');
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
});
it('should call `$browser.$$completeOutstandingRequest()` on success', function() {
$httpBackend.when('GET').respond(200);
$http.get('');
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
fix($http): properly increment/decrement `$browser.outstandingRequestCount` Calling `$http` will not increment `$browser.outstandingRequestCount` until after all (potentially) asynchronous request interceptors have been processed and will decrement it before any (potentially) asynchronous response interceptors have been processed. This can lead to `$browser.notifyWhenNoOutstandingRequests` firing prematurely, which can be problematic in end-to-end tests. This commit fixes this, by synchronizing the increment/decrement operations with `$http`'s internal interceptor promise chain. Fixes #13782 Closes #13862 Closes #14921 BREAKING CHANGE: HTTP requests now update the outstanding request count synchronously. Previously the request count would not have been updated until the request to the server is actually in flight. Now the request count is updated before the async interceptor is called. The new behaviour is correct but it may change the expected behaviour in a small number of e2e test cases where an async request interceptor is being used.
2016-01-27 17:44:47 -06:00
$httpBackend.flush();
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(completeOutstandingRequestSpy).toHaveBeenCalledOnceWith(noop, '$http');
fix($http): properly increment/decrement `$browser.outstandingRequestCount` Calling `$http` will not increment `$browser.outstandingRequestCount` until after all (potentially) asynchronous request interceptors have been processed and will decrement it before any (potentially) asynchronous response interceptors have been processed. This can lead to `$browser.notifyWhenNoOutstandingRequests` firing prematurely, which can be problematic in end-to-end tests. This commit fixes this, by synchronizing the increment/decrement operations with `$http`'s internal interceptor promise chain. Fixes #13782 Closes #13862 Closes #14921 BREAKING CHANGE: HTTP requests now update the outstanding request count synchronously. Previously the request count would not have been updated until the request to the server is actually in flight. Now the request count is updated before the async interceptor is called. The new behaviour is correct but it may change the expected behaviour in a small number of e2e test cases where an async request interceptor is being used.
2016-01-27 17:44:47 -06:00
});
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
it('should call `$browser.$$completeOutstandingRequest()` on error', function() {
fix($http): properly increment/decrement `$browser.outstandingRequestCount` Calling `$http` will not increment `$browser.outstandingRequestCount` until after all (potentially) asynchronous request interceptors have been processed and will decrement it before any (potentially) asynchronous response interceptors have been processed. This can lead to `$browser.notifyWhenNoOutstandingRequests` firing prematurely, which can be problematic in end-to-end tests. This commit fixes this, by synchronizing the increment/decrement operations with `$http`'s internal interceptor promise chain. Fixes #13782 Closes #13862 Closes #14921 BREAKING CHANGE: HTTP requests now update the outstanding request count synchronously. Previously the request count would not have been updated until the request to the server is actually in flight. Now the request count is updated before the async interceptor is called. The new behaviour is correct but it may change the expected behaviour in a small number of e2e test cases where an async request interceptor is being used.
2016-01-27 17:44:47 -06:00
$httpBackend.when('GET').respond(500);
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
$http.get('').catch(noop);
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
fix($http): properly increment/decrement `$browser.outstandingRequestCount` Calling `$http` will not increment `$browser.outstandingRequestCount` until after all (potentially) asynchronous request interceptors have been processed and will decrement it before any (potentially) asynchronous response interceptors have been processed. This can lead to `$browser.notifyWhenNoOutstandingRequests` firing prematurely, which can be problematic in end-to-end tests. This commit fixes this, by synchronizing the increment/decrement operations with `$http`'s internal interceptor promise chain. Fixes #13782 Closes #13862 Closes #14921 BREAKING CHANGE: HTTP requests now update the outstanding request count synchronously. Previously the request count would not have been updated until the request to the server is actually in flight. Now the request count is updated before the async interceptor is called. The new behaviour is correct but it may change the expected behaviour in a small number of e2e test cases where an async request interceptor is being used.
2016-01-27 17:44:47 -06:00
$httpBackend.flush();
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(completeOutstandingRequestSpy).toHaveBeenCalledOnceWith(noop, '$http');
fix($http): properly increment/decrement `$browser.outstandingRequestCount` Calling `$http` will not increment `$browser.outstandingRequestCount` until after all (potentially) asynchronous request interceptors have been processed and will decrement it before any (potentially) asynchronous response interceptors have been processed. This can lead to `$browser.notifyWhenNoOutstandingRequests` firing prematurely, which can be problematic in end-to-end tests. This commit fixes this, by synchronizing the increment/decrement operations with `$http`'s internal interceptor promise chain. Fixes #13782 Closes #13862 Closes #14921 BREAKING CHANGE: HTTP requests now update the outstanding request count synchronously. Previously the request count would not have been updated until the request to the server is actually in flight. Now the request count is updated before the async interceptor is called. The new behaviour is correct but it may change the expected behaviour in a small number of e2e test cases where an async request interceptor is being used.
2016-01-27 17:44:47 -06:00
});
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
it('should increment/decrement `outstandingRequestCount` on error in `transformRequest`',
fix($q): treat thrown errors as regular rejections Previously, errors thrown in a promise's `onFulfilled` or `onRejected` handlers were treated in a slightly different manner than regular rejections: They were passed to the `$exceptionHandler()` (in addition to being converted to rejections). The reasoning for this behavior was that an uncaught error is different than a regular rejection, as it can be caused by a programming error, for example. In practice, this turned out to be confusing or undesirable for users, since neither native promises nor any other popular promise library distinguishes thrown errors from regular rejections. (Note: While this behavior does not go against the Promises/A+ spec, it is not prescribed either.) This commit removes the distinction, by skipping the call to `$exceptionHandler()`, thus treating thrown errors as regular rejections. **Note:** Unless explicitly turned off, possibly unhandled rejections will still be caught and passed to the `$exceptionHandler()`, so errors thrown due to programming errors and not otherwise handled (with a subsequent `onRejected` handler) will not go unnoticed. Fixes #3174 Fixes #14745 Closes #15213 BREAKING CHANGE: Previously, throwing an error from a promise's `onFulfilled` or `onRejection` handlers, would result in passing the error to the `$exceptionHandler()` (in addition to rejecting the promise with the error as reason). Now, a thrown error is treated exactly the same as a regular rejection. This applies to all services/controllers/filters etc that rely on `$q` (including built-in services, such as `$http` and `$route`). For example, `$http`'s `transformRequest/Response` functions or a route's `redirectTo` function as well as functions specified in a route's `resolve` object, will no longer result in a call to `$exceptionHandler()` if they throw an error. Other than that, everything will continue to behave in the same way; i.e. the promises will be rejected, route transition will be cancelled, `$routeChangeError` events will be broadcasted etc.
2016-09-30 20:43:31 +03:00
function() {
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
expect(incOutstandingRequestCountSpy).not.toHaveBeenCalled();
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
$http.get('', {transformRequest: function() { throw new Error(); }}).catch(noop);
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
$rootScope.$digest();
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
expect(completeOutstandingRequestSpy).toHaveBeenCalledOnceWith(noop, '$http');
fix($q): treat thrown errors as regular rejections Previously, errors thrown in a promise's `onFulfilled` or `onRejected` handlers were treated in a slightly different manner than regular rejections: They were passed to the `$exceptionHandler()` (in addition to being converted to rejections). The reasoning for this behavior was that an uncaught error is different than a regular rejection, as it can be caused by a programming error, for example. In practice, this turned out to be confusing or undesirable for users, since neither native promises nor any other popular promise library distinguishes thrown errors from regular rejections. (Note: While this behavior does not go against the Promises/A+ spec, it is not prescribed either.) This commit removes the distinction, by skipping the call to `$exceptionHandler()`, thus treating thrown errors as regular rejections. **Note:** Unless explicitly turned off, possibly unhandled rejections will still be caught and passed to the `$exceptionHandler()`, so errors thrown due to programming errors and not otherwise handled (with a subsequent `onRejected` handler) will not go unnoticed. Fixes #3174 Fixes #14745 Closes #15213 BREAKING CHANGE: Previously, throwing an error from a promise's `onFulfilled` or `onRejection` handlers, would result in passing the error to the `$exceptionHandler()` (in addition to rejecting the promise with the error as reason). Now, a thrown error is treated exactly the same as a regular rejection. This applies to all services/controllers/filters etc that rely on `$q` (including built-in services, such as `$http` and `$route`). For example, `$http`'s `transformRequest/Response` functions or a route's `redirectTo` function as well as functions specified in a route's `resolve` object, will no longer result in a call to `$exceptionHandler()` if they throw an error. Other than that, everything will continue to behave in the same way; i.e. the promises will be rejected, route transition will be cancelled, `$routeChangeError` events will be broadcasted etc.
2016-09-30 20:43:31 +03:00
}
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
);
it('should increment/decrement `outstandingRequestCount` on error in `transformResponse`',
fix($q): treat thrown errors as regular rejections Previously, errors thrown in a promise's `onFulfilled` or `onRejected` handlers were treated in a slightly different manner than regular rejections: They were passed to the `$exceptionHandler()` (in addition to being converted to rejections). The reasoning for this behavior was that an uncaught error is different than a regular rejection, as it can be caused by a programming error, for example. In practice, this turned out to be confusing or undesirable for users, since neither native promises nor any other popular promise library distinguishes thrown errors from regular rejections. (Note: While this behavior does not go against the Promises/A+ spec, it is not prescribed either.) This commit removes the distinction, by skipping the call to `$exceptionHandler()`, thus treating thrown errors as regular rejections. **Note:** Unless explicitly turned off, possibly unhandled rejections will still be caught and passed to the `$exceptionHandler()`, so errors thrown due to programming errors and not otherwise handled (with a subsequent `onRejected` handler) will not go unnoticed. Fixes #3174 Fixes #14745 Closes #15213 BREAKING CHANGE: Previously, throwing an error from a promise's `onFulfilled` or `onRejection` handlers, would result in passing the error to the `$exceptionHandler()` (in addition to rejecting the promise with the error as reason). Now, a thrown error is treated exactly the same as a regular rejection. This applies to all services/controllers/filters etc that rely on `$q` (including built-in services, such as `$http` and `$route`). For example, `$http`'s `transformRequest/Response` functions or a route's `redirectTo` function as well as functions specified in a route's `resolve` object, will no longer result in a call to `$exceptionHandler()` if they throw an error. Other than that, everything will continue to behave in the same way; i.e. the promises will be rejected, route transition will be cancelled, `$routeChangeError` events will be broadcasted etc.
2016-09-30 20:43:31 +03:00
function() {
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
expect(incOutstandingRequestCountSpy).not.toHaveBeenCalled();
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
$httpBackend.when('GET').respond(200);
$http.get('', {transformResponse: function() { throw new Error(); }}).catch(noop);
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
$httpBackend.flush();
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
expect(completeOutstandingRequestSpy).toHaveBeenCalledOnceWith(noop, '$http');
fix($q): treat thrown errors as regular rejections Previously, errors thrown in a promise's `onFulfilled` or `onRejected` handlers were treated in a slightly different manner than regular rejections: They were passed to the `$exceptionHandler()` (in addition to being converted to rejections). The reasoning for this behavior was that an uncaught error is different than a regular rejection, as it can be caused by a programming error, for example. In practice, this turned out to be confusing or undesirable for users, since neither native promises nor any other popular promise library distinguishes thrown errors from regular rejections. (Note: While this behavior does not go against the Promises/A+ spec, it is not prescribed either.) This commit removes the distinction, by skipping the call to `$exceptionHandler()`, thus treating thrown errors as regular rejections. **Note:** Unless explicitly turned off, possibly unhandled rejections will still be caught and passed to the `$exceptionHandler()`, so errors thrown due to programming errors and not otherwise handled (with a subsequent `onRejected` handler) will not go unnoticed. Fixes #3174 Fixes #14745 Closes #15213 BREAKING CHANGE: Previously, throwing an error from a promise's `onFulfilled` or `onRejection` handlers, would result in passing the error to the `$exceptionHandler()` (in addition to rejecting the promise with the error as reason). Now, a thrown error is treated exactly the same as a regular rejection. This applies to all services/controllers/filters etc that rely on `$q` (including built-in services, such as `$http` and `$route`). For example, `$http`'s `transformRequest/Response` functions or a route's `redirectTo` function as well as functions specified in a route's `resolve` object, will no longer result in a call to `$exceptionHandler()` if they throw an error. Other than that, everything will continue to behave in the same way; i.e. the promises will be rejected, route transition will be cancelled, `$routeChangeError` events will be broadcasted etc.
2016-09-30 20:43:31 +03:00
}
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
);
fix($http): properly increment/decrement `$browser.outstandingRequestCount` Calling `$http` will not increment `$browser.outstandingRequestCount` until after all (potentially) asynchronous request interceptors have been processed and will decrement it before any (potentially) asynchronous response interceptors have been processed. This can lead to `$browser.notifyWhenNoOutstandingRequests` firing prematurely, which can be problematic in end-to-end tests. This commit fixes this, by synchronizing the increment/decrement operations with `$http`'s internal interceptor promise chain. Fixes #13782 Closes #13862 Closes #14921 BREAKING CHANGE: HTTP requests now update the outstanding request count synchronously. Previously the request count would not have been updated until the request to the server is actually in flight. Now the request count is updated before the async interceptor is called. The new behaviour is correct but it may change the expected behaviour in a small number of e2e test cases where an async request interceptor is being used.
2016-01-27 17:44:47 -06:00
});
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
describe('with interceptors', function() {
var reqInterceptorDeferred;
var resInterceptorDeferred;
var reqInterceptorFulfilled;
var resInterceptorFulfilled;
beforeEach(module(function($httpProvider) {
reqInterceptorDeferred = null;
resInterceptorDeferred = null;
reqInterceptorFulfilled = false;
resInterceptorFulfilled = false;
$httpProvider.interceptors.push(function($q) {
return {
request: function(config) {
return (reqInterceptorDeferred = $q.defer()).
promise.
finally(function() { reqInterceptorFulfilled = true; }).
then(valueFn(config));
},
response: function() {
return (resInterceptorDeferred = $q.defer()).
promise.
finally(function() { resInterceptorFulfilled = true; });
}
};
});
}));
beforeEach(setupServicesAndSpies);
beforeEach(function() {
$httpBackend.when('GET').respond(200);
});
it('should increment/decrement `outstandingRequestCount` before/after async interceptors',
function() {
expect(reqInterceptorFulfilled).toBe(false);
expect(resInterceptorFulfilled).toBe(false);
expect(incOutstandingRequestCountSpy).not.toHaveBeenCalled();
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
$http.get('');
$rootScope.$digest();
expect(reqInterceptorFulfilled).toBe(false);
expect(resInterceptorFulfilled).toBe(false);
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
reqInterceptorDeferred.resolve();
$httpBackend.flush();
expect(reqInterceptorFulfilled).toBe(true);
expect(resInterceptorFulfilled).toBe(false);
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
resInterceptorDeferred.resolve();
$rootScope.$digest();
expect(reqInterceptorFulfilled).toBe(true);
expect(resInterceptorFulfilled).toBe(true);
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
expect(completeOutstandingRequestSpy).toHaveBeenCalledOnceWith(noop, '$http');
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
}
);
it('should increment/decrement `outstandingRequestCount` on error in request interceptor',
function() {
expect(reqInterceptorFulfilled).toBe(false);
expect(incOutstandingRequestCountSpy).not.toHaveBeenCalled();
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
$http.get('').catch(noop);
$rootScope.$digest();
expect(reqInterceptorFulfilled).toBe(false);
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
reqInterceptorDeferred.reject();
$rootScope.$digest();
expect(reqInterceptorFulfilled).toBe(true);
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
expect(completeOutstandingRequestSpy).toHaveBeenCalledOnceWith(noop, '$http');
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
}
);
it('should increment/decrement `outstandingRequestCount` on error in response interceptor',
function() {
expect(reqInterceptorFulfilled).toBe(false);
expect(resInterceptorFulfilled).toBe(false);
expect(incOutstandingRequestCountSpy).not.toHaveBeenCalled();
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
$http.get('').catch(noop);
$rootScope.$digest();
expect(reqInterceptorFulfilled).toBe(false);
expect(resInterceptorFulfilled).toBe(false);
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
reqInterceptorDeferred.resolve();
$httpBackend.flush();
expect(reqInterceptorFulfilled).toBe(true);
expect(resInterceptorFulfilled).toBe(false);
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
expect(completeOutstandingRequestSpy).not.toHaveBeenCalled();
resInterceptorDeferred.reject();
$rootScope.$digest();
expect(reqInterceptorFulfilled).toBe(true);
expect(resInterceptorFulfilled).toBe(true);
feat(*): implement more granular pending task tracking Previously, all pending async tasks (tracked via `$browser`) are treated the same. I.e. things like `$$testability.whenStable()` and `ngMock#$timeout.verifyNoPendingTasks()` take all tasks into account. Yet, in some cases we might be interested in specific tasks only. For example, if one wants to verify there are no pending `$timeout`s, they don't care if there are other pending tasks, such as `$http` requests. Similarly, one might want to get notified when all `$http` requests have completed and does not care about pending promises. This commit adds support for more granular task tracking, by enabling callers to specify the type of task that is being added/removed from the queue and enabling listeners to be triggered when specific types of tasks are completed (even if there are more pending tasks of different types). The change is backwards compatible. I.e. calling the affected methods with no explicit task-type, behaves the same as before. Related to #14336.
2018-06-16 11:00:47 +03:00
expect(incOutstandingRequestCountSpy).toHaveBeenCalledOnceWith('$http');
expect(completeOutstandingRequestSpy).toHaveBeenCalledOnceWith(noop, '$http');
fix($http): avoid `Possibly Unhandled Rejection` error when the request fails Calling `promise.finally(...)` creates a new promise. If we don't return this promise, the user won't be able to attach an error handler to it and thus won't be able to prevent a potential PUR error. This commit also improves the test coverage for the increment/decrement `outstandingRequestCount` fix. Closes #13869 Closes #14921
2016-07-14 21:59:25 +03:00
}
);
});
// Helpers
function setupServicesAndSpies() {
inject(function($browser, _$http_, _$httpBackend_, _$rootScope_) {
$http = _$http_;
$httpBackend = _$httpBackend_;
$rootScope = _$rootScope_;
incOutstandingRequestCountSpy =
spyOn($browser, '$$incOutstandingRequestCount').and.callThrough();
completeOutstandingRequestSpy =
spyOn($browser, '$$completeOutstandingRequest').and.callThrough();
});
}
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
feat($http): add withCredentials config option
2012-04-03 11:00:52 -07:00
feat($http): support sending XSRF token to whitelisted origins Normally, the XSRF token will not be set for cross-origin requests. With this commit, it is possible to whitelist additional origins, so that requests to these origins will include the XSRF token header. Fixes #7862
2016-07-10 00:23:18 +03:00
describe('XSRF', function() {
var $http;
var $httpBackend;
beforeEach(module(function($httpProvider) {
$httpProvider.xsrfWhitelistedOrigins.push(
'https://whitelisted.example.com',
'https://whitelisted2.example.com:1337/ignored/path');
}));
beforeEach(inject(function(_$http_, _$httpBackend_) {
$http = _$http_;
$httpBackend = _$httpBackend_;
}));
it('should set the XSRF cookie into an XSRF header', function() {
function checkXsrf(secret, header) {
return function checkHeaders(headers) {
return headers[header || 'X-XSRF-TOKEN'] === secret;
};
}
mockedCookies['XSRF-TOKEN'] = 'secret';
mockedCookies['aCookie'] = 'secret2';
$httpBackend.expect('GET', '/url', null, checkXsrf('secret')).respond(null);
$httpBackend.expect('POST', '/url', null, checkXsrf('secret')).respond(null);
$httpBackend.expect('PUT', '/url', null, checkXsrf('secret')).respond(null);
$httpBackend.expect('DELETE', '/url', null, checkXsrf('secret')).respond(null);
$httpBackend.expect('GET', '/url', null, checkXsrf('secret', 'aHeader')).respond(null);
$httpBackend.expect('GET', '/url', null, checkXsrf('secret2')).respond(null);
$http({method: 'GET', url: '/url'});
$http({method: 'POST', url: '/url', headers: {'S-ome': 'Header'}});
$http({method: 'PUT', url: '/url', headers: {'Another': 'Header'}});
$http({method: 'DELETE', url: '/url', headers: {}});
$http({method: 'GET', url: '/url', xsrfHeaderName: 'aHeader'});
$http({method: 'GET', url: '/url', xsrfCookieName: 'aCookie'});
$httpBackend.flush();
});
it('should support setting a default XSRF cookie/header name', function() {
$http.defaults.xsrfCookieName = 'aCookie';
$http.defaults.xsrfHeaderName = 'aHeader';
function checkHeaders(headers) {
return headers.aHeader === 'secret';
}
mockedCookies.aCookie = 'secret';
$httpBackend.expect('GET', '/url', null, checkHeaders).respond(null);
$http.get('/url');
$httpBackend.flush();
});
it('should support overriding the default XSRF cookie/header name per request', function() {
$http.defaults.xsrfCookieName = 'aCookie';
$http.defaults.xsrfHeaderName = 'aHeader';
function checkHeaders(headers) {
return headers.anotherHeader === 'anotherSecret';
}
mockedCookies.anotherCookie = 'anotherSecret';
$httpBackend.expect('GET', '/url', null, checkHeaders).respond(null);
$http.get('/url', {
xsrfCookieName: 'anotherCookie',
xsrfHeaderName: 'anotherHeader'
});
$httpBackend.flush();
});
it('should check the cache before checking the XSRF cookie', inject(function($cacheFactory) {
function checkHeaders(headers) {
return headers['X-XSRF-TOKEN'] === 'foo';
}
function setCookie() {
mockedCookies['XSRF-TOKEN'] = 'foo';
}
var testCache = $cacheFactory('testCache');
spyOn(testCache, 'get').and.callFake(setCookie);
$httpBackend.expect('GET', '/url', null, checkHeaders).respond(null);
$http.get('/url', {cache: testCache});
$httpBackend.flush();
}));
it('should not set an XSRF header for cross-domain requests', function() {
function checkHeaders(headers) {
return isUndefined(headers['X-XSRF-TOKEN']);
}
var requestUrls = [
'https://api.example.com/path',
'http://whitelisted.example.com',
'https://whitelisted2.example.com:1338'
];
mockedCookies['XSRF-TOKEN'] = 'secret';
requestUrls.forEach(function(url) {
$httpBackend.expect('GET', url, null, checkHeaders).respond(null);
$http.get(url);
$httpBackend.flush();
});
});
it('should set an XSRF header for cross-domain requests to whitelisted origins',
inject(function($browser) {
function checkHeaders(headers) {
return headers['X-XSRF-TOKEN'] === 'secret';
}
var currentUrl = 'https://example.com/path';
var requestUrls = [
'https://whitelisted.example.com/path',
'https://whitelisted2.example.com:1337/path'
];
$browser.url(currentUrl);
mockedCookies['XSRF-TOKEN'] = 'secret';
requestUrls.forEach(function(url) {
$httpBackend.expect('GET', url, null, checkHeaders).respond(null);
$http.get(url);
$httpBackend.flush();
});
})
);
});
feat($http): support reponseType Closes #1013
2012-08-04 12:11:00 -07:00
it('should pass timeout, withCredentials and responseType', function() {
feat($http): add withCredentials config option
2012-04-03 11:00:52 -07:00
var $httpBackend = jasmine.createSpy('$httpBackend');
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
$httpBackend.and.callFake(function(m, u, d, c, h, timeout, withCredentials, responseType) {
feat($http): add withCredentials config option
2012-04-03 11:00:52 -07:00
expect(timeout).toBe(12345);
expect(withCredentials).toBe(true);
feat($http): support reponseType Closes #1013
2012-08-04 12:11:00 -07:00
expect(responseType).toBe('json');
feat($http): add withCredentials config option
2012-04-03 11:00:52 -07:00
});
module(function($provide) {
$provide.value('$httpBackend', $httpBackend);
});
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
inject(function($http, $rootScope) {
feat($http): support reponseType Closes #1013
2012-08-04 12:11:00 -07:00
$http({
chore(jshint): enforce jshint for tests Closes #7264
2014-04-26 23:07:28 +03:00
method: 'GET',
url: 'some.html',
timeout: 12345,
withCredentials: true,
responseType: 'json'
feat($http): support reponseType Closes #1013
2012-08-04 12:11:00 -07:00
});
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
$rootScope.$digest();
feat($http): add withCredentials config option
2012-04-03 11:00:52 -07:00
expect($httpBackend).toHaveBeenCalledOnce();
});
$httpBackend.verifyNoOutstandingExpectation = noop;
});
feat($http): Allow setting withCredentials on defaults Closes #1095.
2012-07-29 17:52:19 -07:00
it('should use withCredentials from default', function() {
var $httpBackend = jasmine.createSpy('$httpBackend');
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
$httpBackend.and.callFake(function(m, u, d, c, h, timeout, withCredentials, responseType) {
feat($http): Allow setting withCredentials on defaults Closes #1095.
2012-07-29 17:52:19 -07:00
expect(withCredentials).toBe(true);
});
module(function($provide) {
$provide.value('$httpBackend', $httpBackend);
});
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
inject(function($http, $rootScope) {
feat($http): Allow setting withCredentials on defaults Closes #1095.
2012-07-29 17:52:19 -07:00
$http.defaults.withCredentials = true;
$http({
chore(jshint): enforce jshint for tests Closes #7264
2014-04-26 23:07:28 +03:00
method: 'GET',
url: 'some.html',
timeout: 12345,
responseType: 'json'
feat($http): Allow setting withCredentials on defaults Closes #1095.
2012-07-29 17:52:19 -07:00
});
feat(http): support request/response promise chaining myApp.factory('myAroundInterceptor', function($rootScope, $timeout) { return function(configPromise, responsePromise) { return { request: configPromise.then(function(config) { return config }); response: responsePromise.then(function(response) { return 'ha!'; } }); } myApp.config(function($httpProvider){ $httpProvider.aroundInterceptors.push('myAroundInterceptor'); });
2013-02-26 10:22:12 +01:00
$rootScope.$digest();
feat($http): Allow setting withCredentials on defaults Closes #1095.
2012-07-29 17:52:19 -07:00
expect($httpBackend).toHaveBeenCalledOnce();
});
$httpBackend.verifyNoOutstandingExpectation = noop;
});
feat($http): new $http service, removing $xhr.* Features: - aborting requests - more flexible callbacks (per status code) - custom request headers (per request) - access to response headers - custom transform functions (both request, response) - caching - shortcut methods (get, head, post, put, delete, patch, jsonp) - exposing pendingCount() - setting timeout Breaks Renaming $xhr to $http Breaks Takes one parameter now - configuration object Breaks $xhr.cache removed - use configuration cache: true instead Breaks $xhr.error, $xhr.bulk removed Breaks Callback functions get parameters: response, status, headers Closes #38 Closes #80 Closes #180 Closes #299 Closes #342 Closes #395 Closes #413 Closes #414 Closes #507
2011-08-05 01:24:41 +02:00
});
feat($http): implement mechanism for coalescing calls to $apply in $http When multiple responses are received within a short window from each other, it can be wasteful to perform full dirty-checking cycles for each individual response. In order to prevent this, it is now possible to coalesce calls to $apply for responses which occur close together. This behaviour is opt-in, and the default is disabled, in order to avoid breaking tests or applications. In order to activate coalesced apply in tests or in an application, simply perform the following steps during configuration. angular.module('myFancyApp', []). config(function($httpProvider) { $httpProvider.useApplyAsync(true); }); OR: angular.mock.module(function($httpProvider) { $httpProvider.useApplyAsync(true); }); Closes #8736 Closes #7634 Closes #5297
2014-08-22 18:17:55 -04:00
test($http): fix typo in spec name 'applyAapply' -> 'applyAsync'. Closes #9323
2014-09-29 02:04:10 +03:00
describe('$http with $applyAsync', function() {
feat($http): implement mechanism for coalescing calls to $apply in $http When multiple responses are received within a short window from each other, it can be wasteful to perform full dirty-checking cycles for each individual response. In order to prevent this, it is now possible to coalesce calls to $apply for responses which occur close together. This behaviour is opt-in, and the default is disabled, in order to avoid breaking tests or applications. In order to activate coalesced apply in tests or in an application, simply perform the following steps during configuration. angular.module('myFancyApp', []). config(function($httpProvider) { $httpProvider.useApplyAsync(true); }); OR: angular.mock.module(function($httpProvider) { $httpProvider.useApplyAsync(true); }); Closes #8736 Closes #7634 Closes #5297
2014-08-22 18:17:55 -04:00
var $http, $httpBackend, $rootScope, $browser, log;
beforeEach(module(function($httpProvider) {
$httpProvider.useApplyAsync(true);
}, provideLog));
beforeEach(inject(['$http', '$httpBackend', '$rootScope', '$browser', 'log', function(http, backend, scope, browser, logger) {
$http = http;
$httpBackend = backend;
$rootScope = scope;
$browser = browser;
chore(*): Upgrade to Jasmine 2.4 Highlights: New mechanism to run async tests as Jasmine 2 removed `runs`, `waits` and `waitsFor` The functions `iit`, `ddescribe` and `tthey` were renamed `fit`, `fdescribe` and `fthey` as the originals came from Karma, Karma no longer bundles Jasmine and the new function name comes from Jasmine. Closes #14226
2016-03-13 13:20:30 +01:00
spyOn($rootScope, '$apply').and.callThrough();
spyOn($rootScope, '$applyAsync').and.callThrough();
spyOn($rootScope, '$digest').and.callThrough();
spyOn($browser.defer, 'cancel').and.callThrough();
feat($http): implement mechanism for coalescing calls to $apply in $http When multiple responses are received within a short window from each other, it can be wasteful to perform full dirty-checking cycles for each individual response. In order to prevent this, it is now possible to coalesce calls to $apply for responses which occur close together. This behaviour is opt-in, and the default is disabled, in order to avoid breaking tests or applications. In order to activate coalesced apply in tests or in an application, simply perform the following steps during configuration. angular.module('myFancyApp', []). config(function($httpProvider) { $httpProvider.useApplyAsync(true); }); OR: angular.mock.module(function($httpProvider) { $httpProvider.useApplyAsync(true); }); Closes #8736 Closes #7634 Closes #5297
2014-08-22 18:17:55 -04:00
log = logger;
}]));
it('should schedule coalesced apply on response', function() {
var handler = jasmine.createSpy('handler');
$httpBackend.expect('GET', '/template1.html').respond(200, '<h1>Header!</h1>', {});
$http.get('/template1.html').then(handler);
// Ensure requests are sent
$rootScope.$digest();
feat(ngMock/$httpBackend): flush requests in any order Previously, requests were flushed in the order in which they were made. With this change, it is possible to flush requests in any order. This is useful for simulating more realistic scenarios, where parallel requests may be completed in any order. Partially addresses #13717. Closes #14967
2016-07-29 00:23:30 +03:00
$httpBackend.flush(null, null, false);
feat($http): implement mechanism for coalescing calls to $apply in $http When multiple responses are received within a short window from each other, it can be wasteful to perform full dirty-checking cycles for each individual response. In order to prevent this, it is now possible to coalesce calls to $apply for responses which occur close together. This behaviour is opt-in, and the default is disabled, in order to avoid breaking tests or applications. In order to activate coalesced apply in tests or in an application, simply perform the following steps during configuration. angular.module('myFancyApp', []). config(function($httpProvider) { $httpProvider.useApplyAsync(true); }); OR: angular.mock.module(function($httpProvider) { $httpProvider.useApplyAsync(true); }); Closes #8736 Closes #7634 Closes #5297
2014-08-22 18:17:55 -04:00
expect($rootScope.$applyAsync).toHaveBeenCalledOnce();
expect(handler).not.toHaveBeenCalled();
$browser.defer.flush();
expect(handler).toHaveBeenCalledOnce();
});
it('should combine multiple responses within short time frame into a single $apply', function() {
$httpBackend.expect('GET', '/template1.html').respond(200, '<h1>Header!</h1>', {});
$httpBackend.expect('GET', '/template2.html').respond(200, '<p>Body!</p>', {});
$http.get('/template1.html').then(log.fn('response 1'));
$http.get('/template2.html').then(log.fn('response 2'));
// Ensure requests are sent
$rootScope.$digest();
feat(ngMock/$httpBackend): flush requests in any order Previously, requests were flushed in the order in which they were made. With this change, it is possible to flush requests in any order. This is useful for simulating more realistic scenarios, where parallel requests may be completed in any order. Partially addresses #13717. Closes #14967
2016-07-29 00:23:30 +03:00
$httpBackend.flush(null, null, false);
feat($http): implement mechanism for coalescing calls to $apply in $http When multiple responses are received within a short window from each other, it can be wasteful to perform full dirty-checking cycles for each individual response. In order to prevent this, it is now possible to coalesce calls to $apply for responses which occur close together. This behaviour is opt-in, and the default is disabled, in order to avoid breaking tests or applications. In order to activate coalesced apply in tests or in an application, simply perform the following steps during configuration. angular.module('myFancyApp', []). config(function($httpProvider) { $httpProvider.useApplyAsync(true); }); OR: angular.mock.module(function($httpProvider) { $httpProvider.useApplyAsync(true); }); Closes #8736 Closes #7634 Closes #5297
2014-08-22 18:17:55 -04:00
expect(log).toEqual([]);
$browser.defer.flush();
expect(log).toEqual(['response 1', 'response 2']);
});
it('should handle pending responses immediately if a digest occurs on $rootScope', function() {
$httpBackend.expect('GET', '/template1.html').respond(200, '<h1>Header!</h1>', {});
$httpBackend.expect('GET', '/template2.html').respond(200, '<p>Body!</p>', {});
$httpBackend.expect('GET', '/template3.html').respond(200, '<p>Body!</p>', {});
$http.get('/template1.html').then(log.fn('response 1'));
$http.get('/template2.html').then(log.fn('response 2'));
$http.get('/template3.html').then(log.fn('response 3'));
// Ensure requests are sent
$rootScope.$digest();
// Intermediate $digest occurs before 3rd response is received, assert that pending responses
/// are handled
$httpBackend.flush(2);
expect(log).toEqual(['response 1', 'response 2']);
// Finally, third response is received, and a second coalesced $apply is started
feat(ngMock/$httpBackend): flush requests in any order Previously, requests were flushed in the order in which they were made. With this change, it is possible to flush requests in any order. This is useful for simulating more realistic scenarios, where parallel requests may be completed in any order. Partially addresses #13717. Closes #14967
2016-07-29 00:23:30 +03:00
$httpBackend.flush(null, null, false);
feat($http): implement mechanism for coalescing calls to $apply in $http When multiple responses are received within a short window from each other, it can be wasteful to perform full dirty-checking cycles for each individual response. In order to prevent this, it is now possible to coalesce calls to $apply for responses which occur close together. This behaviour is opt-in, and the default is disabled, in order to avoid breaking tests or applications. In order to activate coalesced apply in tests or in an application, simply perform the following steps during configuration. angular.module('myFancyApp', []). config(function($httpProvider) { $httpProvider.useApplyAsync(true); }); OR: angular.mock.module(function($httpProvider) { $httpProvider.useApplyAsync(true); }); Closes #8736 Closes #7634 Closes #5297
2014-08-22 18:17:55 -04:00
$browser.defer.flush();
expect(log).toEqual(['response 1', 'response 2', 'response 3']);
});
});
feat($http): support custom params serializers Closes #3740 Closes #7429 Closes #9224 Closes #11461
2015-03-30 15:37:04 +02:00
feat($httpProvider): add 'useLegacyPromiseExtensions' configuration The legacy methods, `success` and `error`, have been deprecated. Set this to `false` to cause `$http` to throw an error if these methods are used in the application. For now it defaults to `true`. In a future release we will remove these methods altogether. DEPRECATION NOTICE: The legacy methods 'success' and 'error' on promises returned by $http are now deprecated. Closes #12112 Closes #10508
2015-06-15 00:14:20 +02:00
feat($http): support custom params serializers Closes #3740 Closes #7429 Closes #9224 Closes #11461
2015-03-30 15:37:04 +02:00
describe('$http param serializers', function() {
var defSer, jqrSer;
beforeEach(inject(function($httpParamSerializer, $httpParamSerializerJQLike) {
defSer = $httpParamSerializer;
jqrSer = $httpParamSerializerJQLike;
}));
describe('common functionality', function() {
it('should return empty string for null or undefined params', function() {
expect(defSer(undefined)).toEqual('');
expect(jqrSer(undefined)).toEqual('');
expect(defSer(null)).toEqual('');
expect(jqrSer(null)).toEqual('');
});
it('should serialize objects', function() {
expect(defSer({foo: 'foov', bar: 'barv'})).toEqual('bar=barv&foo=foov');
expect(jqrSer({foo: 'foov', bar: 'barv'})).toEqual('bar=barv&foo=foov');
fix($httpParamSerializerJQLike): follow jQuery logic for nested params Closes #11551 Closes #11635
2015-04-17 17:05:53 +02:00
expect(defSer({someDate: new Date('2014-07-15T17:30:00.000Z')})).toEqual('someDate=2014-07-15T17:30:00.000Z');
expect(jqrSer({someDate: new Date('2014-07-15T17:30:00.000Z')})).toEqual('someDate=2014-07-15T17:30:00.000Z');
feat($http): support custom params serializers Closes #3740 Closes #7429 Closes #9224 Closes #11461
2015-03-30 15:37:04 +02:00
});
});
describe('default array serialization', function() {
it('should serialize arrays by repeating param name', function() {
expect(defSer({a: 'b', foo: ['bar', 'baz']})).toEqual('a=b&foo=bar&foo=baz');
});
fix($httpParamSerializer): ignore functions Closes #16133
2017-07-27 15:09:44 +02:00
it('should NOT serialize functions', function() {
expect(defSer({foo: 'foov', bar: function() {}})).toEqual('foo=foov');
});
feat($http): support custom params serializers Closes #3740 Closes #7429 Closes #9224 Closes #11461
2015-03-30 15:37:04 +02:00
});
describe('jquery array and objects serialization', function() {
it('should serialize arrays by repeating param name with [] suffix', function() {
expect(jqrSer({a: 'b', foo: ['bar', 'baz']})).toEqual('a=b&foo%5B%5D=bar&foo%5B%5D=baz');
expect(decodeURIComponent(jqrSer({a: 'b', foo: ['bar', 'baz']}))).toEqual('a=b&foo[]=bar&foo[]=baz');
});
fix($httpParamSerializerJQLike): call functions as jQuery does Previously, `httpParamSerializerJQLike` stringified function properties without executing them. This commit ensures function properties are executed and the return value is used. Fixes #16138 Closes #16139
2017-07-31 20:07:08 +02:00
it('should serialize arrays with functions', function() {
expect(jqrSer({foo: [valueFn('bar')]})).toEqual('foo%5B%5D=bar'); // foo[]=bar
});
it('should serialize arrays with functions inside objects', function() {
expect(jqrSer({foo: {bar: [valueFn('baz')]}})).toEqual('foo%5Bbar%5D%5B%5D=baz'); // foo[bar][]=baz
});
fix($httpParamSerializerJQLike): follow jQuery logic for nested params Closes #11551 Closes #11635
2015-04-17 17:05:53 +02:00
it('should serialize objects by repeating param name with [key] suffix', function() {
feat($http): support custom params serializers Closes #3740 Closes #7429 Closes #9224 Closes #11461
2015-03-30 15:37:04 +02:00
expect(jqrSer({a: 'b', foo: {'bar': 'barv', 'baz': 'bazv'}})).toEqual('a=b&foo%5Bbar%5D=barv&foo%5Bbaz%5D=bazv');
//a=b&foo[bar]=barv&foo[baz]=bazv
});
fix($httpParamSerializerJQLike): follow jQuery logic for nested params Closes #11551 Closes #11635
2015-04-17 17:05:53 +02:00
fix($httpParamSerializerJQLike): call functions as jQuery does Previously, `httpParamSerializerJQLike` stringified function properties without executing them. This commit ensures function properties are executed and the return value is used. Fixes #16138 Closes #16139
2017-07-31 20:07:08 +02:00
it('should serialize objects with function properties', function() {
expect(jqrSer({a: valueFn('b')})).toEqual('a=b');
});
it('should serialize objects with function properties returning an object', function() {
expect(jqrSer({a: valueFn({b: 'c'})})).toEqual('a=%7B%22b%22:%22c%22%7D'); //a={"b":"c"}
});
fix($httpParamSerializerJQLike): follow jQuery logic for nested params Closes #11551 Closes #11635
2015-04-17 17:05:53 +02:00
it('should serialize nested objects by repeating param name with [key] suffix', function() {
expect(jqrSer({a: ['b', {c: 'd'}], e: {f: 'g', 'h': ['i', 'j']}})).toEqual(
fix(httpParamSerializerJQLike): Follow jQuery for index of arrays of objects Follow jQuery when serializing arrays that contain objects Close #12393 Close #12398
2015-07-21 22:52:50 +02:00
'a%5B%5D=b&a%5B1%5D%5Bc%5D=d&e%5Bf%5D=g&e%5Bh%5D%5B%5D=i&e%5Bh%5D%5B%5D=j');
//a[]=b&a[1][c]=d&e[f]=g&e[h][]=i&e[h][]=j
});
fix($httpParamSerializerJQLike): call functions as jQuery does Previously, `httpParamSerializerJQLike` stringified function properties without executing them. This commit ensures function properties are executed and the return value is used. Fixes #16138 Closes #16139
2017-07-31 20:07:08 +02:00
it('should serialize nested objects with function properties', function() {
expect(jqrSer({foo: {bar: valueFn('barv')}})).toEqual('foo%5Bbar%5D=barv'); //foo[bar]=barv
});
it('should serialize nested objects with function properties returning an object', function() {
expect(jqrSer({foo: {bar: valueFn({bav: 'barv'})}})).toEqual('foo%5Bbar%5D=%7B%22bav%22:%22barv%22%7D'); //foo[bar]={"bav":"barv"}
});
fix(httpParamSerializerJQLike): Follow jQuery for index of arrays of objects Follow jQuery when serializing arrays that contain objects Close #12393 Close #12398
2015-07-21 22:52:50 +02:00
it('should serialize objects inside array elements using their index', function() {
expect(jqrSer({a: ['b', 'c'], d: [{e: 'f', g: 'h'}, 'i', {j: 'k'}]})).toEqual(
'a%5B%5D=b&a%5B%5D=c&d%5B0%5D%5Be%5D=f&d%5B0%5D%5Bg%5D=h&d%5B%5D=i&d%5B2%5D%5Bj%5D=k');
//a[]=b&a[]=c&d[0][e]=f&d[0][g]=h&d[]=i&d[2][j]=k
fix($httpParamSerializerJQLike): follow jQuery logic for nested params Closes #11551 Closes #11635
2015-04-17 17:05:53 +02:00
});
fix(httpParamSerializerJQLike): Follow jQuery for `null` and `undefined` Follow jQuery when serializing `null` and `undefined`. Closes: #15969 Closes: #15971
2017-05-07 18:05:20 +02:00
it('should serialize `null` and `undefined` elements as empty', function() {
expect(jqrSer({items:['foo', 'bar', null, undefined, 'baz'], x: null, y: undefined})).toEqual(
'items%5B%5D=foo&items%5B%5D=bar&items%5B%5D=&items%5B%5D=&items%5B%5D=baz&x=&y=');
//items[]=foo&items[]=bar&items[]=&items[]=&items[]=baz&x=&y=
});
feat($http): support custom params serializers Closes #3740 Closes #7429 Closes #9224 Closes #11461
2015-03-30 15:37:04 +02:00
});
});
Reference in New Issue Copy Permalink