| Age | Commit message (Collapse) | Author |
|---|
|
This change brings Angular's JSONP behaviour closer in line with jQuery's. It will no longer treat
a callback called with no data as an error, and will no longer support IE8 via the onreadystatechanged
event.
BREAKING CHANGE:
Previously, the JSONP backend code would support IE8 by relying on the readystatechanged events. This
is no longer the case, as these events do not provide adequate useful information for deeming whether
or not a response is an error.
Previously, a JSONP response which did not pass data into the callback would be given a status of -2,
and treated as an error. Now, this situation will instead be given a status of 200, despite the lack
of data. This is useful for interaction with certain APIs.
Previously, the onload and onerror callbacks were added to the JSONP script tag. These have been
replaced with jQuery events, in order to gain access to the event object. This means that it is now
difficult to test if the callbacks are registered or not. This is possible with jQuery, using the
$.data("events") method, however it is currently impossible with jqLite. This is not expected to
break applications.
Closes #4987
Closes #6735
|
|
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
|
|
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
|
|
Closes #4830
|
|
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
|
|
|
|
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.
|
|
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
|
|
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.
|
|
|
|
|
