Restsharp: le port est supprimé de l'en-tête de l'hôte

Créé le 21 févr. 2018 · 35Commentaires · Source: restsharp/RestSharp

Comportement attendu

Restsharp doit envoyer l'en-tête de l'hôte tel quel sans modifier le port dans la valeur de l'en-tête de l'hôte.
https://github.com/minio/minio-dotnet/pull/212 apporte Restsharp 106.2.1 au lieu de Restsharp.Netcore (version non officielle avec support .netcore). Cependant, nous avons trouvé des erreurs de non-concordance de signature car l'authentificateur personnalisé utilisé par le sdk minio dotnet crée une signature d'autorisation en utilisant ip:port comme valeur pour l'en-tête "Host". Restsharp httpclient semble supprimer le port, car la trace du serveur n'affiche que ip dans la valeur d'en-tête de l'hôte.

Comportement réel

le port est supprimé de la valeur d'en-tête "Host" dans Restsharp 106.2.1

Étapes pour reproduire le problème

clonez le sdk minio-dotnet et obtenez le correctif https://github.com/minio/minio-dotnet/pull/212
➜ minio-dotnet git:(02cbcb5) ✗ restauration dotnet ; construction dotnet
➜ minio-dotnet git:(02cbcb5) ✗ dotnet run --project SimpleTest
2.
3.

Caractéristiques

Édition : 106.2.1
Plate-forme : Linux/Windows
Sous-système :

Trace de la pile

minio-dotnet client side trace
---------------------------------------
Full URL of Request http://192.168.1.157:9000/
Request completed in 90.1376 ms, Request: {
  "resource": "/",
  "parameters": [
    {
      "name": "x-amz-content-sha256",
      "value": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "type": "HttpHeader"
    },
    {
      "name": "Host",
      "value": "192.168.1.157:9000",
      "type": "HttpHeader"
    },
    {
      "name": "x-amz-date",
      "value": "20180221T205958Z",
      "type": "HttpHeader"
    },
    {
      "name": "Authorization",
      "value": "AWS4-HMAC-SHA256 Credential=minio/20180221/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=db0fbcc9aa66975a530a2621962a87787559289a218da881420686263da862df",
      "type": "HttpHeader"
    },
    {
      "name": "Accept",
      "value": "application/json, application/xml, text/json, text/x-json, text/javascript, text/xml",
      "type": "HttpHeader"
    }
  ],
  "method": "GET",
  "uri": "http://192.168.1.157:9000/"
}, Response: {
  "statusCode": 403,
  "content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><Key></Key><BucketName></BucketName><Resource>/</Resource><RequestId>3L137</RequestId><HostId>3L137</HostId></Error>",
  "headers": [
    {
      "Name": "Accept-Ranges",
      "Value": "bytes",
      "Type": 3,
      "ContentType": null
    },
    {
      "Name": "Server",
      "Value": "Minio/DEVELOPMENT.GOGET, (linux; amd64)",
      "Type": 3,
      "ContentType": null
    },
    {
      "Name": "Vary",
      "Value": "Origin",
      "Type": 3,
      "ContentType": null
    },
    {
      "Name": "X-Amz-Request-Id",
      "Value": "151572E9DCF94747",
      "Type": 3,
      "ContentType": null
    },
    {
      "Name": "Date",
      "Value": "Wed, 21 Feb 2018 20:59:58 GMT",
      "Type": 3,
      "ContentType": null
    },
    {
      "Name": "Transfer-Encoding",
      "Value": "chunked",
      "Type": 3,
      "ContentType": null
    },
    {
      "Name": "Content-Type",
      "Value": "application/xml",
      "Type": 3,
      "ContentType": null
    }
  ],
  "responseUri": "http://192.168.1.157:9000/",
  "errorMessage": null
}
I'm not handling the Minio.Exceptions.MinioException.

Unhandled Exception: System.AggregateException: One or more errors occurred. (Minio API responded with message=The request signature we calculated does not match the signature you provided. Check your key and signing method.) (Minio API responded with message=The request signature we calculated does not match the signature you provided. Check your key and signing method.) ---> Minio.Exceptions.MinioException: Minio API responded with message=The request signature we calculated does not match the signature you provided. Check your key and signing method.
   at Minio.MinioClient.ParseError(IRestResponse response) in /home/kris/code/minio-dotnet/Minio/MinioClient.cs:line 475
   at Minio.MinioClient.<>c.<.ctor>b__78_0(IRestResponse response) in /home/kris/code/minio-dotnet/Minio/MinioClient.cs:line 70
   at Minio.MinioClient.HandleIfErrorResponse(IRestResponse response, IEnumerable`1 handlers, DateTime startTime) in /home/kris/code/minio-dotnet/Minio/MinioClient.cs:line 502
   at Minio.MinioClient.<ExecuteTaskAsync>d__81.MoveNext() in /home/kris/code/minio-dotnet/Minio/MinioClient.cs:line 349
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Minio.MinioClient.<ListBucketsAsync>d__0.MoveNext() in /home/kris/code/minio-dotnet/Minio/ApiEndpoints/BucketOperations.cs:line 52
   --- End of inner exception stack trace ---
   at System.AggregateException.Handle(Func`2 predicate)
   at SimpleTest.Program.Main(String[] args) in /home/kris/code/minio-dotnet/SimpleTest/Program.cs:line 47

Server side trace: 
--------------------------
➜  minio git:(debugnet) minio server ~/ex                               
Drive Capacity: 6.9 GiB Free, 221 GiB Total

Endpoint:  http://192.168.1.157:9000  http://172.17.0.1:9000  http://172.18.0.1:9000  http://172.19.0.1:9000  http://172.20.0.1:9000  http://127.0.0.1:9000
AccessKey: minio 
SecretKey: minio123 

Browser Access:
   http://192.168.1.157:9000  http://172.17.0.1:9000  http://172.18.0.1:9000  http://172.19.0.1:9000  http://172.20.0.1:9000  http://127.0.0.1:9000

Command-line Access: https://docs.minio.io/docs/minio-client-quickstart-guide
   $ mc config host add myminio http://192.168.1.157:9000 minio minio123

Object API (Amazon S3 compatible):
   Go:         https://docs.minio.io/docs/golang-client-quickstart-guide
   Java:       https://docs.minio.io/docs/java-client-quickstart-guide
   Python:     https://docs.minio.io/docs/python-client-quickstart-guide
   JavaScript: https://docs.minio.io/docs/javascript-client-quickstart-guide
   .NET:       https://docs.minio.io/docs/dotnet-client-quickstart-guide
signed headers .... map[X-Amz-Content-Sha256:[e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855] X-Amz-Date:[20180221T205638Z] Host:[192.168.1.157]]

Source

poornas

Commentaire le plus utile

Élevons-le !

niemyjski le 22 mars 2018

👍4

Tous les 35 commentaires

Existe-t-il un moyen de le reproduire dans un test simple?

alexeyzimarev le 24 févr. 2018

https://github.com/poornas/restsharp-test - il s'agit d'un projet simple utilisant restsharp pour effectuer un appel List buckets au serveur minio. Il utilise un authentificateur personnalisé - vous verrez qu'il échoue en raison d'une incompatibilité de signature. une fois la requête transmise à restsharp, le port est supprimé avant d'être transmis au serveur.

poornas le 26 févr. 2018

Merci. Je vais regarder et essayer de le réparer.

alexeyzimarev le 26 févr. 2018

👍2

Merci!

niemyjski le 27 févr. 2018

@alexeyzimarev Des idées sur ce qui pourrait causer cela ?

niemyjski le 28 févr. 2018

@alexeyzimarev , avez-vous déjà eu l'occasion de vous pencher là-dessus ? Merci

poornas le 5 mars 2018

Je vérifie maintenant

alexeyzimarev le 5 mars 2018

J'ai cloné votre repro et je vois ceci:

  "parameters": [
...
    {
      "name": "Host",
      "value": "play.minio.io:9000",
      "type": "HttpHeader"
    }

Voulez-vous dire que les paramètres de la requête sont corrects mais que la valeur n'est pas correctement envoyée au serveur ?

alexeyzimarev le 5 mars 2018

@alexeyzimarev , c'est correct - la trace que vous voyez ci-dessus est avant d'appeler executeAsync. Lorsque ExecuteAsync est appelé, Restsharp invoque la méthode Authenticate, où nous définissons l'en-tête d'autorisation de signature basé sur url:port dans l'authentificateur personnalisé. Le port semble être supprimé par Restsharp avant de toucher le serveur et après l'appel Authenticate().

poornas le 5 mars 2018

Des mises à jour à ce sujet ? Nous sommes assez bloqués là-dessus.

niemyjski le 14 mars 2018

Désolé, je n'ai pas pu regarder cela pour l'instant. S'il est très critique, peut-être pourriez-vous passer une heure à le déboguer ?

alexeyzimarev le 14 mars 2018

J'ai jeté un coup d'œil rapide à cela. Pour autant que je sache, le problème ici n'est pas réellement avec RestSharp, mais est en fait HttpWebRequest dans System.Net !

Au moment où RestSharp a transmis la demande à System.Net, la propriété Host (Uri) dans le HttpWebRequest contient toujours les informations de port. Cependant, lorsque .SendRequest() est appelé, l'en-tête Host utilisé est rempli uniquement par l'URI Host, pas host et port .

Voici une capture d'écran de mon débogueur sur le lien ci-dessus.
screen shot 2018-03-22 at 11 22 52 am

Cela va clairement à l'encontre de la spécification HTTP qui respecte l'utilisation des ports.

Quelqu'un, s'il vous plaît, corrigez-moi si je me trompe, car je n'ai jamais trouvé de bogue dans le framework dotnet, et généralement quand je pense que j'en ai - je ne l'ai pas fait. Sinon, je suppose que les prochaines étapes seraient de soulever ce problème sur le dépôt CoreFX ?

twgraham le 22 mars 2018

Élevons-le !

niemyjski le 22 mars 2018

👍4

Terminé - voyons si c'est légitime où se trouve le bogue ou non.

twgraham le 22 mars 2018

Juste curieux - est-ce que quelqu'un sait s'il s'agit d'une régression avec le récent .NET Core ? (2.1) Ou avec la dernière stable (2.0) ? Ou différence entre .NET Framework et .NET Core, ou différence entre le système d'exploitation Windows et Linux ? ("ne sais pas" est une bonne réponse, merci !)

karelz le 22 mars 2018

@karelz TBH j'ai examiné ce problème pour résoudre un autre problème afin que je puisse arrêter de recevoir des avertissements du compilateur 😆 pour moi, c'est un "je ne sais pas", je n'ai essayé cela que sur .NET Core 2.0 sur MacOS. Cette bibliothèque n'a été mise à niveau que récemment (des mois peut-être) pour prendre en charge .NET Core uniquement sur .NET Framework. Peut-être que @alexeyzimarev en saurait plus ?

twgraham le 22 mars 2018

OK, donc vous savez au moins : Cela fonctionne sur .NET Framework (Windows) et échoue sur .NET Core 2.0 (Mac). Est-ce le bon résumé ?

karelz le 22 mars 2018

Non - à partir d'autres threads dans lesquels je suis, je dirais que toutes les plates-formes échouent sur .NET Core 2.0, et je ne connais pas .NET Framework.

twgraham le 22 mars 2018

@karelz Je dirais que cette hypothèse serait correcte. Je viens de passer d'un framework complet à .net core/standard, puis les tests ont échoué. Je ne sais pas s'il s'agit d'une régression par rapport à 1.x car nous avons seulement essayé de migrer vers la norme .net 2.0

niemyjski le 22 mars 2018

👍1

@niemyjski merci pour la confirmation. C'est une information suffisante à ce stade. Je recherchais juste des faits / expériences connus.

karelz le 22 mars 2018

Est-ce que nous gardons ce problème ouvert ?

alexeyzimarev le 22 mars 2018

Le correctif dans CoreFx est dans le PR : https://github.com/dotnet/corefx/pull/28375

caesar-chen le 22 mars 2018

🎉2

Oui :)

Merci
-Blake Niemyjski

Le jeudi 22 mars 2018 à 15h57, Caesar Chen [email protected]
a écrit:

Le correctif dans CoreFx est dans le PR : dotnet/corefx#28375
https://github.com/dotnet/corefx/pull/28375
—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375454963 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AA-So67a2QfPq72jMHNxaSCBhDXiWXOMks5thBAygaJpZM4SOXLx
.

niemyjski le 23 mars 2018

Y avait-il une raison pour laquelle nous ne pouvions pas passer à HttpClient qui est beaucoup plus rapide
et plus facile à travailler? Il n'y aurait pas ce problème ?

Merci
-Blake Niemyjski

Le ven. 23 mars 2018 à 7 h 14, Blake Niemyjski [email protected]
a écrit:

Oui :)
Merci
-Blake Niemyjski
Le jeudi 22 mars 2018 à 15h57, Caesar Chen [email protected]
a écrit:
Le correctif dans CoreFx est dans le PR : dotnet/corefx#28375
https://github.com/dotnet/corefx/pull/28375
—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375454963 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AA-So67a2QfPq72jMHNxaSCBhDXiWXOMks5thBAygaJpZM4SOXLx
.

niemyjski le 23 mars 2018

@niemyjski tu veux dire que le passage de RestSharp utilise HttpClient au lieu de HttpWebRequest ?

alexeyzimarev le 23 mars 2018

Oui :)

Merci
-Blake Niemyjski

Le vendredi 23 mars 2018 à 9h22, Alexey Zimarev [email protected]
a écrit:

@niemyjski https://github.com/niemyjski vous voulez dire que vous éteignez
RestSharp utilise HttpClient au lieu de HttpWebRequest ?
—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375680769 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AA-So0cbK66_Nq-MRdk0xwdb7sLPSGUoks5thQUUgaJpZM4SOXLx
.

niemyjski le 23 mars 2018

@niemyjski la question était l'une _ou_ une autre, _oui_ n'est vraiment pas une réponse valable :)

Si vous voulez dire que RestSharp devrait utiliser HttpClient - je suis un pro, mais la dernière fois que j'ai essayé, il a fallu beaucoup de travail pour faire correspondre tous les paramètres du RestClient.

alexeyzimarev le 25 mars 2018

Oui, nous devrions passer à HttpClient qui a beaucoup plus de flexibilité, a de meilleures performances et une API moderne dont nous savons qu'elle fonctionne partout. Nous pourrions faire quelques changements de rupture et bousculer le majeur :)

niemyjski le 25 mars 2018

Ouais, ça me va, mais je ne le fais pas seul. J'ai essayé et c'était trop de travail. Je supprimerais également les appels asynchrones qui acceptent les rappels. ContinueWith devrait être très bien.

alexeyzimarev le 25 mars 2018

👍1

On dirait que cela a été fusionné dans la version 2.1, devrions-nous publier un nightly qui fait référence au nouvel aperçu 2 bits et nous pouvons déplacer d'autres packages longtemps ? Existe-t-il des solutions de contournement que nous pouvons faire pour < 2.1 runtimes/libs ?

niemyjski le 20 avr. 2018

Je n'ai aucune idée des solutions de contournement

alexeyzimarev le 20 avr. 2018

Je dois d'abord faire une version avant de pouvoir modifier l'avant-première pour référencer l'aperçu 2.1

alexeyzimarev le 20 avr. 2018

Cela a-t-il été résolu ? Les packages 2.1 rtm sont sur nuget.

niemyjski le 1 juin 2018

Donc, vous devez essayer d'utiliser 2.1 et voir s'ils l'ont corrigé ?

alexeyzimarev le 1 juin 2018

@niemyjski mon commentaire du 20 avril est stupide. Je n'ai pas besoin de pointer quoi que ce soit. La bibliothèque se compile en .NET Standard 2.0. L'erreur est causée par un bogue dans le runtime .NET Core 2.0, donc dès que vous reconstruisez votre application avec .NET Core 2.1, si le problème est résolu, il devrait commencer à fonctionner. Désolé pour la confusion.

alexeyzimarev le 1 juin 2018

Cette page vous a été utile?

0 / 5 - 0 notes