Partager via

Uri limites de longueur supprimées

Les méthodes qui créent Uri des instances (constructeurs et TryCreate méthodes de fabrique) ont historiquement limité la longueur de la chaîne d’URI à environ 65 000 caractères (les limites exactes varient légèrement selon le format d’entrée). Ces limites ont été levées de telle sorte qu’il n’existe pratiquement aucune limite supérieure sur la durée Uri d’utilisation des instances.

Version introduite

.NET 10

Comportement précédent

Auparavant, il n’était pas possible de créer une Uri instance dont la longueur a dépassé environ 65 000 caractères. Un code tel que l'exemple suivant a généré un UriFormatException avec le message « URI non valide : la chaîne d’URI est trop longue ».

new Uri($"https://host/{new string('a', 100_000)}");

Nouveau comportement

À compter de .NET 10, Uri les instances contenant de grandes quantités de données peuvent maintenant être créées. Par exemple:

string largeQuery = ...;
return new Uri($"https://someService/?query={Uri.EscapeDataString(largeQuery)}");

Les restrictions supprimées s’appliquent principalement aux chemins d’accès, aux requêtes et aux fragments en tant que composants les plus pratiques pour transporter de grandes quantités de données. Les composants tels que le schéma et l’hôte peuvent toujours appliquer certaines limites de longueur. Les limitations pratiques s'appliquent également à mesure que vous approchez des limites de longueur string. Vous ne pouvez donc pas (ni devriez-vous) utiliser Uri pour représenter un fichier de 10 Go.

Type de changement cassant

Ce changement est un changement de comportement.

Raison de la modification

La plupart des serveurs HTTP appliquent des restrictions de longueur stricte sur les URL qu’ils sont prêts à accepter dans les requêtes. Les limites sont généralement beaucoup plus basses que les limites précédentes de Uri. Toutefois, étant donné que Uri est le type d’échange de facto dans .NET pour les informations de type URI, les limites précédentes ont réduit son utilisation dans certains scénarios, sans bonnes solutions de contournement à part la suppression de l’utilisation de Uri dans l’ensemble des contrats d’API.

Les principaux scénarios pour les grands Uri sont les suivants :

  • data: uris, qui contiennent des objets blob binaires arbitraires encodés en Base64. Celles-ci peuvent être transmises en dehors de la ligne de requête HTTP. Par exemple, ils peuvent faire partie du corps de la demande et peuvent donc être arbitrairement volumineux. Uri peut désormais être utilisé pour représenter des URI de données contenant des fichiers plus volumineux.
  • Chaînes de requête volumineuses. Uri est souvent utilisé comme type d’échange entre les systèmes, même s’il ne sera jamais envoyé dans le cadre d’une requête HTTP. Les informations de demande utilisateur sont souvent encodées dans le cadre de la chaîne de requête. Par conséquent, le nouveau comportement permet de tels scénarios, même lorsque la quantité de données augmente.

Pour la plupart des utilisateurs, aucune action n’est requise.

Si vous vous appuyez sur Uri pour imposer des restrictions de longueur dans le cadre de votre validation d’entrée, vous devez maintenant vérifier vous-même la longueur, de préférence avant de construire l’instance Uri. Comme la plupart des serveurs HTTP appliquent des limites de longueur beaucoup plus strictes dans la pratique, les entrées très longues ont déjà été susceptibles d’entraîner des échecs lorsqu’elles sont envoyées dans le cadre d’une requête HTTP. Vous pouvez constater que votre scénario bénéficierait d’une validation de longueur encore plus stricte que Uri celle effectuée précédemment.

API affectées

  • Last updated on