https://github.com/dotnet/aspnetcore/blob/main/src/Components/Components/src/ChangeDetection.cs doesn't account for Guid which will result in unnecessary renders.

The "src" directory contains a number of JS files that are added to the base copy of RN. It is not a complete source tree itself. Renaming to "patches" would increase clarity of intent, and follow OSS "patch-package" conventions.

Describe the bug

The current implementation of the authorization header parsing has (at least) the following issues:

• A value can't contain any commas
• A value can't start or end with a doublequote
• A value can't contain special characters
  • HTTP Headers only allow ASCII characters
  • There is no option to encode/decode the values (using base64 or urlencoding)
• When a value c

We can build much smaller Mono runtime for .NET Core purposes by simply removing code we don't need in this configuration. We did a few easy initial steps but we can go much further.

This list is not comprehensive but parts like

• Culture Data
• Any PAL related code
• Unused icalls

Feature Request

What feature are you suggesting?

Overview:

Currently, the range list implementation performs linear search on the FindOverlaps method. The purpose of this method is finding all ranges that overlaps with the range that is passed as argument. This can be improved with the use of interval trees, a data structure designed for fast insertion, removal and lookup of int

Whenever I submit a GET request to the api/public/groups endpoint, the "collections" field for each group returns "None" on every group, even if they have access to collections. I can verify that the

Remove logging line, or modify from ch.Info to ch.Trace:
https://github.com/dotnet/machinelearning/blob/5dbfd8acac0bf798957eea122f1413209cdf07dc/src/Microsoft.ML.Mkl.Components/SymSgdClassificationTrainer.cs#L813

For my text dataset, this logging line dumps ~100 pages of floats to my console. That level of verbosity is unneeded at the Info level.

I'd recommend just removing the loggin

The original issue was reported in dotnet/performance#1701:

// Benchmark Process Environment Information:
// Runtime=.NET 6.0.0 (6.0.21.11801), X64 RyuJIT
// GC=Concurrent Workstation
// Job: Job-AQTFSE(PowerPlanMode=00000000-0000-0000-0000-000000000000, IterationTime=250.0000 ms, MaxIterationCount=20, MinIterationCount=15, WarmupCount=1)

OverheadJitting 

Expected Behavior / New Feature

Support sticky sessions for ServiceDiscoveryProviders

Actual Behavior / Motivation for New Feature

When using websockets with ocelot in a distributed system, problem can arise since ocelot, as far as i know, doesn't support sticky sessions when working with service discovery providers.

The functionality could be great if it could work with both consul