Repository navigation
LOC-7549: decode gzip binary downloads and report the real binding version - #71
Open
07souravkunda wants to merge 1 commit into
Open
07souravkunda wants to merge 1 commit into
07souravkunda wants to merge 1 commit into
Conversation
…rsion downloadBinary used WebClient.DownloadFile, which never decodes Content-Encoding. The binary download endpoint is moving gzip-capable bindings to binaries/release/latest_gzip, whose objects are stored with Content-Encoding: gzip and served gzip regardless of Accept-Encoding, so this binding would have saved the gzip stream as the binary. It now downloads with HttpClient + AutomaticDecompression (GZip | Deflate), streams to disk, honours the same proxy, and deletes a partial file if the download fails. GenerateAssemblyInfo was false (since the 2020 SDK-style csproj move) and the library has no AssemblyInfo, so the csproj <AssemblyVersion> never reached the DLL: every release reported User-Agent browserstack-local-csharp/0.0.0000.0000 (5,462 of 5,464 C# endpoint calls in the 7 days to 2026-10-26). Generating it lets local-service tell this release, which decodes gzip, from older ones that must keep the uncompressed path. Tests: - downloadBinary against a local HttpListener: gzip-encoded response saved decoded, plain response saved as-is, 404 leaves no file. - assembly version is generated and flows into the version string. Both new tests fail on the pre-change code. Also run against the staged gzip object on CloudFront: 36,317,952 B, prod SHA-256, `--version` 8.9. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the
|
vivianludrick
approved these changes
Oct 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two fixes, so the C# binding can be moved onto the gzip-encoded binary download (about 3.3× less CDN egress):
downloadBinarydecodesContent-Encoding: gzip. It previously usedWebClient.DownloadFile, which writes the response bytes as received, so a gzip-encoded binary would be saved compressed and fail to start. It now usesHttpClientwithAutomaticDecompression = GZip | Deflate, the same client typefetchSourceUrlalready uses, and streams the response to disk. The proxy handling is unchanged, and a partial file is deleted if the download fails.GenerateAssemblyInfohas beenfalsesince the 2020 SDK-style csproj migration (d14811c), and the library has noAssemblyInfo.cs. As a result,<AssemblyVersion>never reached the DLL, and every release has sentUser-Agent: browserstack-local-csharp/0.0.0000.0000. In the 7 days to 2026-10-26, that was 5,462 of the 5,464 C# calls to/binary/api/v1/endpoint; the other 2 sent no version. With the attribute generated, this release reports e.g.browserstack-local-csharp/3.1.0001.0000.JIRA: https://browserstack.atlassian.net/browse/LOC-7549
Related:
latest_gzipto bindings that decode it. For C#, only when the reported version isn't0.0.latest_gzip/.Why the version fix is needed
latest_gzip/objects are stored withContent-Encoding: gzip, and S3/CloudFront send gzip whateverAccept-Encodingthe client sends. local-service must therefore give that path only to C# builds that contain fix 1. Every release in the field reports0.0.0000.0000, so without fix 2 the new release would be indistinguishable from the old ones. With it:browserstack-local-csharp/0.0.0000.0000(all current releases)latest_unzip(unchanged)browserstack-local-csharp/…/Unknownlatest_unzipbrowserstack-local-csharp/3.1.0001.0000and later (this change)latest_gzip, once the flag is onNot in this PR
The version bump and release are left to the release branch, as usual.
Testing
dotnet test "BrowserStackLocal Unit Tests"(.NET 6, macOS): 35 passed, 0 failed. The new tests are:TestDownloadBinaryDecodesGzipContentEncoding: a localHttpListenerserves a 2 MB binary withContent-Encoding: gzip, and the saved file must equal the original bytes;TestDownloadBinarySavesUncompressedResponseAsIs: a plain response is saved unchanged;TestDownloadBinaryFailureLeavesNoPartialFile: a 404 throws and leaves no file;TestBindingVersionComesFromTheAssembly: the assembly version isn't0.0.0.0and flows intoGetVersionStringFromAssemblyEmbedded.WebClientdownload makes the gzip test fail;GenerateAssemblyInfo=falsemakes the version test fail.downloadBinary()was pointed at a gzip-encoded staging copy of the 8.9 darwin binary on CloudFront (binaries/LOC-7549_gzip_poc/, 10,156,640 B on the wire). It saved 36,317,952 B with the prod SHA-256 (9091089b…), and--versionprintedBrowserStack Local version 8.9.msbuildbuild and integration tests in CI.🤖 Generated with Claude Code