* [Foundation] Do not get in an infinite loop with empty creds.
As decribed in the issue, when the credentials for the base auth are set
to be empty the request reaches a timeout.
The inner issue is that when we have empty credentials the query that
is performed to the credentials db of the system throws an exception.
This exception is not raised to our code, but simply prints out in stderr.
When this situation occurs we get in an infinite loop in which we keep
sending the same credentials, we get another challenge, but the OS does
not do the right thing, we believe that we have to provide the creds
again (which are the same) and we get another challenge.. this goes on
an on until we reach the timeout.
Fortunately we know the number of failed challenges and the failure
response. With this information we can deduce if we already sent the
credentials, and if we did, do not set them again. In this case, the OS
sees no credentials in out delegate, uses the default handler and
correctly returns a 401.
fixes: https://github.com/xamarin/xamarin-macios/issues/8342
fixes: https://github.com/xamarin/xamarin-macios/issues/8344
This change allows to ignore the use of cookies and cookie containers in
the NSUrlSessionHandler. There are two different cookie containers to
consider:
1. The native NSHttoCookieStorage.
2. The managed CookieContainer.
If the native one is set to null, the native code will not use a cookie
storage, which is used as a flag to ignore the managed one.
There is an interesting situation, we allow different types of sessions.
From the cookie storage point of view, Default and Background sessions
are the same, but Ephemeral is not, since we only want to store in ram
the cookies and do not share them.
This supposes a problem because Apple does not provide any API that will
allow to determine the session type use in the configuration. The
workaround has been to hide the direct native call for the configuration
and add an enum value that can later be accessed in the
NSUrlSessionHandler. Of course things cannot be that easy. When a
session is created with the configuration, it creates a copy, and the
internal session configuration does not longer have the flag, therefore,
we need to store the session type in the handler.
Fixes: https://github.com/xamarin/xamarin-macios/issues/7659
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
There are two important things to look at this:
1. That we do set the cookies that are present in the CookieContainer in
the request. That is, we need to set Cookie headers for all of them.
2. That if we receive a Set-Cookie from the server, the CookieContainer
gets correctly updated else we will have issues since we do not respect
the data sent from the server side.
Tests show both that we are setting the Cookie header and that we honour
the Set-Cookie header.
Fixes: https://github.com/xamarin/xamarin-macios/issues/5665
1. Instead of fetching the managed response's cookies twice, and then
comparing them to themselves, fetch the managed response's cookies once and
then the native response's cookies once, and compare that. This way the
test does what it's actually supposed to do!
2. Don't pass if we fail to get the managed response's cookies.
3. Improve assertions to verify the actual cookie content as well.
4. Improve diagnostics if an exception was thrown by checking for the
exception first instead of failing due to something else being different
(since the underlying cause of the difference is the exception, that's what
will have the most information about the failure).
5. Use httpbin.org instead of microsoft.com, since microsoft.com does UA
sniffing and returns different results between the http handlers :/
## Miscellaneous fixes
* Fixed
`/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/builds/mono-ios-sdk-destdir/ios-sources/external/linker/src/linker/Linker.Steps/OutputStep.cs(110,15): error CS0246: The type or namespace name ‘OutputException’ could not be found (are you missing a using directive or an assembly reference?) [/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/mmp/mmp.csproj]`
* Changed the name of the method that is used from linker. Because of this commit 6be26771b9
* Added `OutputException.cs` file on `mtouch.csproj`.
* Removing enter_gc_safe and exit_gc_safe because now it's already gc_safe in this part of code, after a mono change.
* Added known exceptions to LLVM exception list.
* Needs `ifdef` because of this https://github.com/mono/mono/pull/17260.
* Bump MIN_MONO_VERSION to 6.8.0.41 and point MIN_MONO_URL to the PR.
* Add ENABLE_IOS=1 and ENABLE_MAC=1.
* Added switch to disable packaged mono build
* [Tests] Ignore tests that fail on 32b.
Ignore the test on 32b, and filled issue: https://github.com/mono/mono/issues/17752
* [Tests] Ignore a couple of tests causing OOM.
Hopefully fixes https://github.com/xamarin/maccore/issues/1659 for good.
* Ignore `MM0135` test on Catalina+ because it needs Xcode 9.4.
* [monotouch-test] Add null checks for teardown when test didn't run because of a too early OS version.
* [CFNetwork]: Http 2.0 requires OS X 10.11 or later.
Check whether `_HTTPVersion2_0` is available and fallback to HTTP 1.1 otherwise.
## Bring HttpClient from CoreFX
* #7346
* This bumps Mono to use https://github.com/mono/mono/pull/17645 (which is the 2019-10 backport
of https://github.com/mono/mono/pull/17628).
* The big user-visible change is in regards to certificate validation, everything below are just
some minor adjustments to tests.
### SocketsHttpHandler
CoreFX uses a completely new `HttpClientHandler` implementation called `SocketsHttpHandler`,
which you can find at https://github.com/dotnet/corefx/tree/release/3.0/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler.
Since this is not based on the web stack anymore, it does not use any of the related APIs such
as `ServicePointManager` or `WebException`.
### Certificate Validation Changes
There is a new API called `HttpClientHandler.ServerCertificateCustomValidationCallback`.
- https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.servercertificatecustomvalidationcallback?view=netframework-4.8
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Unix.cs (L154)
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Windows.cs (L383)
The `ServicePointManager.ServerCertificateValidationCallback` is no longer invoked and on
certificate validation failure, `AuthenticationException` (from `System.Security.Authentication`)
is thrown instead of `WebException`.
At the moment, the `NSUrlSessionHandler` still uses it's own validation callback and also still
throws `WebException` on failure; we should probably look into making this consistent with the
other handlers.
### Minor adjustments related to internal Mono APIs
* `HttpContent.SerializeToStreamAsync()` is now `protected` (changed from `protected internal`).
- src/Foundation/NSUrlSessionHandler.cs: changed overload accordingly.
- src/System.Net.Http/CFContentStream.cs: likewise.
* `HttpHeaders.GetKnownHeaderKind()` is an internal Mono API.
There is a new internal API called `System.Net.Http.PlatformHelper.IsContentHeader(key)`
which exists in both the old as well as the new implementation.
The correct way of doing it with the CoreFX handler is
`HeaderDescriptor.TryGet (key, out var descriptor) && descriptor.HeaderType == HttpHeaderType.Content`
### Minor adjustments to tests.
* `HttpClientHandler.MaxRequestContentBufferSize` is now longer supported, you can set it to
any non-negative value, the getter will always return 0.
See c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Core.cs (L18).
- tests/linker/ios/link sdk/HttpClientHandlerTest.cs: removed assertion from test.
* `HttpMessageInvoker.handler` is a `protected private` field - in the CoreFX handler, it is
called `_handler` and `private`. This is accessed via reflection by some of the tests, which are
now using the new name.
- tests/mmptest/src/MMPTest.cs: here
- tests/mtouch/MTouch.cs: here
* tests/monotouch-test/System.Net.Http/MessageHandlers.cs:
Adjust `RejectSslCertificatesServicePointManager` to reflect the certificate validation
changes described above.
- FIXME: There was an `Assert.Ignore()` related to `NSUrlSessionHandler` and macOS 10.10;
I removed that to reenable the test because the description linked to an old issue in
the private repo that was referenced by several "Merged" PR's, so it looked to me that
this might have already been fixed - and I also didn't see why it would fail there.
Use a single point where the different enpoints can be found so that
if they need to be updated (server issues or other) it is a simple
change that will affect all tests in monotouch-tests
* [foundation] Expose AllowsCellularAccess on NSUrlSessionHandler (#6059)
This property was always set to `true` but it can be useful to turn it
off (and that was not easy with the existing implementation)
* [Foundation] Ensure that we allow celullar data by default until the user says otherwise. #6762
The default value in the NSUrlSession is to allow cellular data. This
small change closes the issue, since users will not have an unexpected
result.
Later we need to provide a proper fix to allow the property to be
exposed AND used the value of the session.
Fixes: https://github.com/xamarin/xamarin-macios/issues/6762
* [Foundation] Ensure that we allow celullar data by default until the user says otherwise. #6762
The default value in the NSUrlSession is to allow cellular data. This
small change closes the issue, since users will not have an unexpected
result.
Later we need to provide a proper fix to allow the property to be
exposed AND used the value of the session.
Fixes: https://github.com/xamarin/xamarin-macios/issues/6762
Our 3 different handlers were inconsistent with each others. Only the
managed version, `HttpClientHandler`, was throwing the documented
`HttpRequestException` exception.
The inconsistency make this hard to consume from .net standard libraries
even more when the type is not, itself, available in .net standard
stack trace (for NSUrlSessionHandler)
```
2019-07-02 10:58:08.352 gh6439[18579:15880723] System.Net.WebException: The Internet connection appears to be offline. ---> Foundation.NSErrorException: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_kCFStreamErrorCodeKey=50, NSUnderlyingError=0x283b6d350 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={_kCFStreamErrorCodeKey=50, _kCFStreamErrorDomainKey=1}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <55894EBD-B898-4803-9981-46317EEFE280>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <55894EBD-B898-4803-9981-46317EEFE280>.<1>"
), NSLocalizedDescription=The Internet connection appears to be offline., NSErrorFailingURLStringKey=https://www.microsoft.com/fr-ca/, NSErrorFailingURLKey=https://www.microsoft.com/fr-ca/, _kCFStreamErrorDomainKey=1}
--- End of inner exception stack trace ---
at System.Net.Http.NSUrlSessionHandler.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x001d4] in /Users/poupou/git/xcode11/xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:541
at System.Net.Http.HttpClient.SendAsyncWorker (System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x0009e] in /Users/poupou/git/xcode11/xamarin-macios/external/mono/mcs/class/System.Net.Http/System.Net.Http/HttpClient.cs:281
```
stack trace (for CFNetworkHandler)
```
2019-07-02 11:04:35.407 gh6439[18580:15881497] CoreFoundation.CFException: The operation couldn’t be completed. Network is down
at System.Net.Http.CFNetworkHandler.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken, System.Boolean isFirstRequest) [0x002f2] in /Users/poupou/git/xcode11/xamarin-macios/src/System.Net.Http/CFNetworkHandler.cs:266
at System.Net.Http.CFNetworkHandler.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00034] in /Users/poupou/git/xcode11/xamarin-macios/src/System.Net.Http/CFNetworkHandler.cs:199
at System.Net.Http.HttpClient.SendAsyncWorker (System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x0009e] in /Users/poupou/git/xcode11/xamarin-macios/external/mono/mcs/class/System.Net.Http/System.Net.Http/HttpClient.cs:281
```
references:
* https://github.com/xamarin/xamarin-macios/issues/6439
* https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.postasync?view=netstandard-2.0#System_Net_Http_HttpClient_PostAsync_System_String_System_Net_Http_HttpContent_System_Threading_CancellationToken_
This might be a race issue when dealing with the trust of the certs,
there is not much information in
https://github.com/xamarin/maccore/issues/1645 except the fact that we
are getting a null exception.
In this fix, we will first ensure that we did get the exception, later
confirm the exception type. To improve the debugging of the test, next
time it fails, we will get the content string to try and understand what
happened with the validation (did we return part of the stream or
headers when we shouldn't?)
Basic application (size) for doing an `HttpClient.GetAsync`, release/llvm, 64bits only
- NSUrlSessionHandler (master): 6.4 MB
- NSUrlSessionHandler (PR#5936): 7.7 MB
- NSUrlSessionHandler (this PR): 6.4 MB
The size increase occurs because of the reference to .net `X509*` types.
This brings a lot of additional code, including managed cryptographic
code, inside the application - even when the feature is **not** used.
The solution is to expose an API that only use native (OS) types, which
are mostly already part of the application. This has a very low impact
on existing applications.
It's still possible to hook back to .NET validation if needed (it should
not in most cases) but, in this case, the extra price will only be
_paid_ if used (and can be lower if the code is needed by something else
from the application).
In comparison using other `HttpClient` handler produce app sizes of
- HttpClientHandler (managed): 10.4 MB
- CFNetworkHandler: 6.8 MB
Based on/supersede https://github.com/xamarin/xamarin-macios/pull/5733
Fix https://github.com/xamarin/xamarin-macios/issues/4170
Basic application (size) for doing an `HttpClient.GetAsync`, release/llvm, 64bits only
- NSUrlSessionHandler (master): 6.4 MB
- NSUrlSessionHandler (PR#5936): 7.7 MB
- NSUrlSessionHandler (this PR): 6.4 MB
The size increase occurs because of the reference to .net `X509*` types.
This brings a lot of additional code, including managed cryptographic
code, inside the application - even when the feature is **not** used.
The solution is to expose an API that only use native (OS) types, which
are mostly already part of the application. This has a very low impact
on existing applications.
It's still possible to hook back to .NET validation if needed (it should
not in most cases) but, in this case, the extra price will only be
_paid_ if used (and can be lower if the code is needed by something else
from the application).
In comparison using other `HttpClient` handler produce app sizes of
- HttpClientHandler (managed): 10.4 MB
- CFNetworkHandler: 6.8 MB
Based on/supersede https://github.com/xamarin/xamarin-macios/pull/5733
Fix https://github.com/xamarin/xamarin-macios/issues/4170
In some cases, httpbin might return errors or other results. In that
case, we cannot assert that the auth headers are not present. We set the
test to inconclusive to ensure that we do not fail due to the external
page.
Fixes https://github.com/xamarin/maccore/issues/1453
We have issue https://github.com/xamarin/maccore/issues/701 that states
that there is no exception. Get the received response to check against
null and help debug the issue next time it happens in the CI bots.
The bots sometimes have issues with the network. We do not want red
builds due to a problem in the connection. Lets set the test to
inclonclusive since we cannot assert the headers that have been sent.
Fixes https://github.com/xamarin/maccore/issues/1332
The response object does not have all the cookie values, instead we must
rust the cookie storage which can be used to retrieve ALL the cookies
for a task.
The header value has to be created manually because the native objects
do not expose a valid way to get the header. Tests have been added to
ensure we return the same as the managed client.
Fixes https://github.com/xamarin/xamarin-macios/issues/5148
* Make it clearer when a timeout happens that a timeout happened by asserting
exactly that.
* Don't assert after getting the (unexpected) result from the network request,
since asserting will throw an exception, which will be caught and stored,
and then later in the test we assert that an exception was thrown. So
asserting just after a successful network request effectively hides any
failures, since we're now passing because of the assertion exception. Ops.
* Fix many version checks to be based on Xcode version instead of iOS version.
* Added/fixed a few expected values according to platform version to match behavior in older macOS versions.
Store strings in the exception data when converting CFError to CFException, to
make sure the data stored is serializable (which is apparently a requirement
with the reference sources).
https://bugzilla.xamarin.com/show_bug.cgi?id=46626
Manuel de la Pena
Rolf Bjarne Kvinge
Jo Shields
Vincent Dondain
Sebastien Pouliot
monojenkins
Manuel de la Pena
Timothy Risi