* Fix a bunch of lints
* Copy modified source to other libHC projects
* Unfix some lints :P
* Unfix a lint that's not relevant till OkHttp upgrade
* Remove an unused method
* Empty commit to bump CI
* Temporarily rename java path to junk
* Rename back with better casing
* Temporarily rename java path to junk for VS builds
* Rename back with better casing
* Change casing in .androidproj files
* Empty commit to bump CI
* Second empty commit to bump CI
* Drop Android 19 from the Android Studio-compatible build
* Consolidate externalNativeBuild blocks
* Remove common Gradle config, move reduced config into individual projects
Do not assume the caller is building with `/Applications/Xcode.app`.
Some environments use other paths like `/Applications/Xcode_12.1.app`.
Ask `xcode-select -p` for the path to the Xcode `/Developer` directory.
Within `libHttpClient.xcodeproj`, it will use the matching Xcode.
Fixes: #563
Co-authored-by: Jason Sandlin <jasonsa@microsoft.com>
* Make iOS NOWEBSOCKETS targets have same name but be sub-directory-ed
* Disable header maps for all libHC static lib targets
* Add missing prefix header and missing include dir to libHttpClient_macOS target
Co-authored-by: Jason Sandlin <jasonsa@microsoft.com>
If a call completes with either a zero byte payload or an error, the async lib will try to call Cleanup on the call provider early, instead of the normal cleanup which occurs after the completion event has been fired. This early cleanup can create a race condition with XAsyncCancel as follows:
XAsyncCancel is called. Early in the method it acquires a reference on the state structure.
The provider completes its DoWork with zero payload or error and rolls out of the method.
Early cleanup of the provider now happens.
XAsyncCancel continues and tries to call Cancel on the provider.
The provider is likely to crash now because it has already run its cleanup code.
This race was observed with the networking stack on Xbox.
My fix for this is to introduce another "cleanup location" and to change the code that allows cleanup after DoWork to only set this value if the current location is the default Destructor setting. The net effect of this is if the race occurs the async provider cleanup is deferred to state cleanup and loses out on the early cleanup optimization. This seemed better than ditching the early cleanup route entirely.
* Don't bother installing OpenSSL docs/man pages/etc
* SSL targets merge libssl and libcrypto and are depended on by libHC static lib targets
* Add NOWEBSOCKETS framework target
* Add macOS NOWEBSOCKETS framework target
* Add xcschemes to libHttpClient workspace to build the _NOWEBSOCKETS targets
* Empty commit to force fresh CI
* Disable arm64 support for 'Any Mac' target
* Alphabetize
* Update a couple vestigial fields
* Clean up SSLDummy copyright header
* Empty commit to force fresh CI
On Android if a network request failed due to network issues, the Android code set a failure on both the network call object as well as the async call. Because the async call was indicating a failure as well, the retry logic was never kicking in.
Co-authored-by: Jason Sandlin <jasonsa@microsoft.com>
The current blocking version of HCCleanup has 3 major flaws:
- It always uses the system task queue, which may be undesirable by some clients
- It blocks waiting for the internal work to complete, which could cause a deadlock
- It does not expose a result so in the case of multiple libHttpClient initializations it is impossible to tell if the memory hooks are safe to remove
This change simply exposes the internal asynchronous cleanup functionality allowing the caller control to bypass all these issues
If a task queue is terminated while tasks are still being dispatched, the logic that drains the queue before termination can get into an infinite loop. The drain logic needs to pop items off the queue and those that should not be removed are re-added. The first one to be re-added is remembered as a sentinel so the loop knows when to quit. If that item gets dispatched, the loop never terminates.
With this change we put all the items to re-add to the queue into a local buffer and then push them back onto the queue later.
There was a minor bug fix in the Windows OS tree to clear the header data of a task queue before it is deleted so if someone tried to use a released task queue handle we could catch it early. If you reused right after releasing the un-allocated memory could still look like a valid task queue and this will cause crashes later on.
* Add error log line for WINHTTP_CALLBACK_STATUS_SECURE_FAILURE
* Add WINHTTP_CALLBACK_FLAG_SECURE_FAILURE to WinHttpSetStatusCallback() as WINHTTP_CALLBACK_FLAG_ALL_NOTIFICATIONS doesn't really include all notifications
* Remove unreferenced formal parameter
* Specify CMake target in build.gradle instead of using dummy .so workaround
* Bump Gradle and plugin versions
* Add comments on workaround
* Pin NDK version
* Add HCHttpCallRequestSetSSLValidation(). Implemented for WinHttp only
* Convert tabs to spaces
* Ensure HCHttpCallRequestSetSSLValidation() and related implementations are only defined on platforms using WinHTTP
Co-authored-by: Luca <40400240@users.noreply.github.com>
In order to have the schemes for libHttpClient's project not show up and clutter parenting workspaces, I'm adding a workspace next to the existing project and moving ownership of the schemes from the project to the new workspace.
With this change I'm also renaming the existing *_mac targets and schemes to *_macOS to match more widely accepted convention.
* Adding new workspace
* Setting autocreate schemes to false
* Moving libHttpClient schemes from project to workspace
* Renaming *_mac schemes and targets to *_macOS
This PR fixes a random FAIL_FAST crash when completing an async call and fixes an issue where if you call XAsyncGetResults before a call is complete the async block's internal context gets corrupted.
Sasha Weiss
Brad King
John L
Brian Pepin
Ramsey
Jason Sandlin
Matt VanderKolk
Luca Beltrami
Luca Vezzaro
MSFT-Heba