| Age | Commit message (Collapse) | Author |
|---|
|
PR #5547 introduced conversion of all 0 status codes to 404 for cases
where no response was recieved (previously this was done for the
file:// protocol only). But this mechanism is too eager and
masks legitimate cases where status 0 should be returned. This commits
reverts to the previous mechanism of handling 0 status code for the
file:// protocol (converting 0 to 404) while retaining the returned
status code 0 for all the protocols other than file://
Fixes #6074
Fixes #6155
|
|
|
|
|
|
|
|
WebKit added support for the json responseType value on 09/03/2013
https://bugs.webkit.org/show_bug.cgi?id=73648. Versions of Safari prior to 7 are known to throw when
setting the value "json" as the response type. Other older browsers implementing the responseType.
Other browsers with infrequent update cycles may also be affected.
The json responseType value can be ignored if not supported, because JSON payloads are parsed on the
client-side regardless.
Closes #6115
Closes #6122
|
|
"json""
This reverts commit 431bad01835f0294eb159d5b08101d5904828147.
|
|
WebKit added support for the json responseType value on 09/03/2013
https://bugs.webkit.org/show_bug.cgi?id=73648. Versions of Safari prior to 7 are known to throw when
setting the value "json" as the response type. Other older browsers implementing the responseType.
Other browsers with infrequent update cycles may also be affected.
The json responseType value can be ignored if not supported, because JSON payloads are parsed on the
client-side regardless.
Closes #6115
Closes #6122
|
|
|
|
window.XMLHttpRequest is not always available in IE8 despite it not running in quirks mode,
in which case Angular should be using the ActiveXObject instead. Just checking the browser
version is taking too many shortcuts.
Closes #5677
Closes #5679
|
|
Closes #4464
Closes #4738
Closes #5636
|
|
Android 4.1 stock browser also returns status code 0 when
a template is loaded via `http` and the application is cached using
appcache.
Fixes #1356.
Closes #5547.
|
|
When you cancel a JSONP request, angular deletes the callback for it. However the script still executes, and since the callback is now deleted and undefined, the script throws an exception visible in the console. The quick fix for this is not to delete the callback, but replace it with `angular.noop`.
Closes #5615
Closes #5616
|
|
|
|
|
|
|
|
IE8's native XHR doesn't support PATCH requests, but the ActiveX one does.
I'm also removing the noxhr error doc because nobody will ever get that error.
Closes #2518
Closes #5043
|
|
On mobile webkit `onreadystatechange` might by called multiple times
with `readyState===4` caused by xhrs that are resolved while the app is
in the background.
Fixes #5426.
|
|
apps
Previously if an app was running from file:// origin we would always return either
http 200 or 404 depending on whether the response was present.
This changes the behavior so that we do this only if the protocol of the request
(not the origin) is file:// and only if the status code is 0.
Closes #4436
Closes #4587
Closes #4514
|
|
|
|
IE8, IE9 and IE10 can use `script.onreadystate` so up till now we have been using this
if the sniffer says we are on IE.
But IE11 now does not support `script.onreadystate` and only supports the more standard
`script.onload` and `script.onerror`.
IE9 and IE10 do support `script.onload` and `script.onerror`. So now we only test whether
we are on IE8 or earlier before using `script.onreadystate`.
See http://pieisgood.org/test/script-link-events/
jQuery just uses all these handlers at once and hopes for the best, but since IE9 and IE10
support both sets of handlers, this could cause the handlers to be run more than once.
jQuery also notes that there is a potential memory leak in IE unless we remove the handlers
from the script object once they are run. So we are doing this too, now.
Closes #4523
Closes #4527
Closes #4922
|
|
When a request is aborted, it makes no sense to read the response headers or text.
Also in IE9, trying to read data (either response headers or text) from an aborted request
throws an Error c00c023f.
Fixes #4913
Closes #4940
|
|
|
|
The location service, and other portions of the application,
were relying on a complicated regular expression to get parts of a URL.
But there is already a private urlUtils provider,
which relies on HTMLAnchorElement to provide this information,
and is suitable for most cases.
In order to make urlUtils more accessible in the absence of DI,
its methods were converted to standalone functions available globally.
The urlUtils.resolve method was renamed urlResolve,
and was refactored to only take 1 argument, url,
and not the 2nd "parse" boolean.
The method now always returns a parsed url.
All places in code which previously wanted a string instead of a parsed
url can now get the value from the href property of the returned object.
Tests were also added to ensure IPv6 addresses were handled correctly.
Closes #3533
Closes #2950
Closes #3249
|
|
This is a breaking change. To migrate to the new behavior,
delete or set headers to `undefined` to avoid having them sent.
To restore the old behavior, override `$httpBackendProvider`
with the old implementation.
Closes #2984
|
|
The `XMLHttpRequest.send` spec defines different semantics for `null`
than for an empty String: an empty String should be sent with a
`Content-Type` of `text/plain`, whereas `null` should have no
`Content-Type` header set.
Closes #2149
|
|
See #1468
|
|
|
|
- add toThrowNg matcher
|
|
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
|
|
Documentation implies that timeout works for all requests, though it
only works with XHR. To implement:
- Change $httpBackend to set a timeout for JSONP requests which will
immediately resolve the request when fired.
- Cancel the timeout when requests are completed.
|
|
Closes #1051
|
|
If responseType is defined and the request fails for one reason or another
the .response property returned falsy value which caused dereferencing of
.responseText. If the responseType was a blob or document then an error
was thrown.
To prevent this, I'm checking for responseType first and based on that
dereferencing .response or .responseText.
We need to keep on checking .responseText because that's the original XHR
response api that is still needed for IE8 and 9.
Closes #1922
|
|
A workaround for https://bugzilla.mozilla.org/show_bug.cgi?id=608735
In FF getAllResponseHeaders() returns null if the request is the result of CORS.
Tried to format the code so that when a FF patch is released and gains enough
traction it can easily be selected and deleted. Heavily inspired by jQuery's
patch for the same bug. This patch falls short of passing through custom headers
but covers all of the "simple response headers" in the spec at
http://www.w3.org/TR/cors/
This commit should get reverted once Firefox 21 gets out.
Closes #1468
|
|
Closes #1013
|
|
we now have two types of namespaces:
- true namespace: angular.* - used for all global apis
- virtual namespace: ng.*, ngMock.*, ... - used for all DI modules
the virual namespaces have services under the second namespace level (e.g. ng.)
and filters and directives prefixed with filter: and directive: respectively
(e.g. ng.filter:orderBy, ng.directive:ngRepeat)
this simplifies urls and makes them a lot shorter while still avoiding name collisions
|
|
|
|
this was never meant to be a public api used by apps. I refactored
the code to hide the functionality.
BREAKING CHANGE: $browser.addJs method was removed
apps that depended on this functionality should either use many of the
existing script loaders or create a simple helper method specific to the
app.
|
|
|
|
|
|
|
