Optimize parser and make it recognize a class of URIs that don't need extra
handling: no escapes, no funny characters, already (nearly or completely)
normalized.
Have a class specifically for those URIs which retains the original
input string without having allocate any further strings.
R=floitsch@google.com
Committed: 00090a0c72
Review URL: https://codereview.chromium.org/2086613003 .
Previously, Socket::ListInterfaces failed to set the os_error out
parameter causing a crash in the caller. This change sets an error here.
I've also added NetworkInterface.listSupported, which returns false on
Android, and true everywhere else. ifaddrs.h continues not to exist in
the NDK, so in order to support NetworkInterface.list, we'd have to
reimplement it, or find a suitable reimplementation somewhere.
related #26329R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1916223003 .
Symptom of the problem:
Set your Linux workstation (or Mac or MIPS board) to the Europe/London timezone
and the corelib/date_time test will fail, claiming that 1/1/1970 was a Wednesday
(it was actually a Thursday, trust me, I was already born).
Problem:
The implementation of DateTime in the VM relies on Unix time_t, the number of
seconds since the Epoch (1/1/1970 UTC). When asked for the weekday of a given
time, our implementation limits itself to a 32-bit positive range of time_t.
If the time falls outside of this range, the implementation picks an equivalent
time in the valid range with the same weekday, also in leap year or not, etc...
The issue is that DateTime is using the underlying OS in an inconsistent manner.
Let's take the example above: 1/1/1970 in the Europe/London timezone.
First, the number of seconds since the Epoch in UTC is calculated, here 0.
Then, the timezone offset at the given time is calculated using the underlying
OS. In this case, an historical deviation is taken into account. Indeed, London
stayed on British Summer Time between 27 October 1968 and 31 October 1971. See
https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation for
details.
Our resulting time is therefore negative (one hour difference with UTC).
When asked about the weekday of this time, the implementation notices that the
time is not in the positive range and picks an "equivalent" time in the future.
It then asks the underlying OS about the timezone offset for this time, which
is 0 (usually no daylight saving time in January in London). Unfortunately,
this time is not really equivalent, because it ignores the original historical
deviation. The result is wrongly equivalent to 12/31/1969 23:00 in London, i.e.
a Wednesday, and not a Thursday as expected.
Solution:
We should use the underlying OS in a consistent way, by simply allowing the
value of time_t passed to the underlying OS to be negative, which is legal.
R=floitsch@google.com, rmacnak@google.com
Review URL: https://codereview.chromium.org/1845483002 .
Any PKCS12 container, not just those containing a private key, can be
protected by a password. This change adds an optional named `password`
parameter to other SecurityContext calls, and plumbs it through to
the calls reading PKCS12 data.
R=whesse@google.com
Review URL: https://codereview.chromium.org/1699163002 .
Looking forward to using platform specific APIs, this container type is
more common on MacOS and Windows, and is the only container type
supported by the native iOS API.
R=whesse@google.com
Review URL: https://codereview.chromium.org/1687533002 .
Implements SecurityContext.setTrustedCertificates in terms of the new
function. This requires setTrustedCertificates to return a Future,
and removing the `directory` named argument as it is not possible to
implement with BoringSSL without blocking IO.
R=whesse@google.com
Review URL: https://codereview.chromium.org/1665433002 .
