Restsharp: el puerto se está eliminando del encabezado del host

Creado en 21 feb. 2018 · 35Comentarios · Fuente: restsharp/RestSharp

Comportamiento esperado

Restsharp debe enviar el encabezado del Host tal como está sin modificar el puerto en el valor del encabezado del Host.
https://github.com/minio/minio-dotnet/pull/212 trae Restsharp 106.2.1 en lugar de Restsharp.Netcore (versión no oficial con soporte .netcore). Sin embargo, encontramos errores de discrepancia de firma porque el autenticador personalizado que usa minio dotnet sdk crea una firma de autorización usando ip:port como valor para el encabezado "Host". Restsharp httpclient parece estar eliminando el puerto, ya que el seguimiento del servidor muestra solo ip en el valor del encabezado del host.

Comportamiento real

el puerto se está eliminando del valor del encabezado "Host" en Restsharp 106.2.1

Pasos para reproducir el problema

clone minio-dotnet sdk y obtenga el parche https://github.com/minio/minio-dotnet/pull/212
➜ minio-dotnet git:(02cbcb5) ✗ restauración de dotnet;construcción de dotnet
➜ minio-dotnet git:(02cbcb5) ✗ dotnet run --project SimpleTest
2.
3.

Especificaciones

Versión: 106.2.1
Plataforma: Linux/Windows
Subsistema:

seguimiento de pila

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]]

Fuente

poornas

Comentario más útil

¡Vamos a levantarlo!

niemyjski en 22 mar. 2018

👍4

Todos 35 comentarios

¿Hay alguna forma de reproducirlo en una prueba simple?

alexeyzimarev en 24 feb. 2018

https://github.com/poornas/restsharp-test : este es un proyecto básico que usa restsharp para hacer una llamada de List buckets al servidor minio. Utiliza un autenticador personalizado: verá que falla debido a la falta de coincidencia de la firma. una vez que la solicitud se pasa a restsharp, el puerto se elimina antes de pasar al servidor.

poornas en 26 feb. 2018

Gracias. Echaré un vistazo y trataré de arreglarlo.

alexeyzimarev en 26 feb. 2018

👍2

¡Gracias!

niemyjski en 27 feb. 2018

@alexeyzimarev ¿ Alguna idea sobre qué podría estar causando esto?

niemyjski en 28 feb. 2018

@alexeyzimarev , ¿ya tuviste la oportunidad de investigar esto? Gracias

poornas en 5 mar. 2018

Comprobando ahora

alexeyzimarev en 5 mar. 2018

He clonado tu repro y veo esto:

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

¿Quiere decir que los parámetros en la solicitud están bien pero el valor no se envía correctamente al servidor?

alexeyzimarev en 5 mar. 2018

@alexeyzimarev , eso es correcto: el seguimiento que ve arriba es antes de llamar a executeAsync. Cuando se llama a ExecuteAsync, Restsharp invoca el método de autenticación, donde estamos configurando el encabezado de autorización de firma basado en url: puerto en el autenticador personalizado. El puerto parece haber sido eliminado por Restsharp antes de acceder al servidor y después de la llamada Authenticate().

poornas en 5 mar. 2018

¿Alguna actualización sobre esto? Estamos bastante bloqueados en esto.

niemyjski en 14 mar. 2018

Lo siento, no pude ver esto todavía. Si es muy crítico, ¿pueden pasar una hora depurándolo?

alexeyzimarev en 14 mar. 2018

Eché un vistazo rápido a esto. Por lo que puedo decir, el problema aquí no es en realidad con RestSharp, ¡sino que en realidad es HttpWebRequest en System.Net !

Para cuando RestSharp entregó la solicitud a System.Net, la propiedad Host (Uri) en HttpWebRequest aún contiene la información del puerto. Sin embargo, cuando se llama a .SendRequest() , el encabezado de host que se usa se completa solo con el host de URI, no con el host y el puerto .

Aquí hay una captura de pantalla de mi depurador en el enlace de arriba.
screen shot 2018-03-22 at 11 22 52 am

Esto claramente va en contra de la especificación HTTP que respeta el uso de puertos.

Alguien, por favor, corríjame si me equivoco, porque nunca he encontrado un error en el marco dotnet y, por lo general, cuando creo que lo he hecho, no lo he hecho. De lo contrario, supongo que los próximos pasos serían plantear este problema en el repositorio de CoreFX.

twgraham en 22 mar. 2018

¡Vamos a levantarlo!

niemyjski en 22 mar. 2018

👍4

Hecho, veamos si esto es legítimo donde está el error o no.

twgraham en 22 mar. 2018

Solo curiosidad: ¿alguien sabe si se trata de una regresión con .NET Core reciente? (2.1) ¿O con el último establo (2.0)? ¿O la diferencia de .NET Framework frente a .NET Core, o la diferencia entre OS Windows y Linux? ("No sé" es una buena respuesta, ¡gracias!)

karelz en 22 mar. 2018

@karelz TBH investigué este problema para resolver otro problema para poder dejar de recibir advertencias del compilador 😆 para mí es un "no sé", solo probé esto en .NET Core 2.0 en MacOS. Esta biblioteca se actualizó recientemente (quizás meses) para admitir .NET Core sobre solo .NET Framework. ¿Quizás @alexeyzimarev podría saber más?

twgraham en 22 mar. 2018

Bien, al menos ya sabes: funciona en .NET Framework (Windows) y falla en .NET Core 2.0 (Mac). ¿Es ese resumen correcto?

karelz en 22 mar. 2018

No, de otros subprocesos en los que estoy, diría que falla en todas las plataformas en .NET Core 2.0, y no sé sobre .NET Framework.

twgraham en 22 mar. 2018

@karelz diría que esa suposición sería correcta. Acabo de cambiar de marco completo a .net core/estándar y luego se rompieron las pruebas. No estoy seguro de si se trata de una regresión de 1.x, ya que solo intentamos migrar a .net estándar 2.0

niemyjski en 22 mar. 2018

👍1

@niemyjski gracias por la confirmación. Eso es suficiente información en este punto. Solo estaba explorando hechos / experiencias conocidas.

karelz en 22 mar. 2018

¿Mantenemos este tema abierto?

alexeyzimarev en 22 mar. 2018

La solución en CoreFx está en PR: https://github.com/dotnet/corefx/pull/28375

caesar-chen en 22 mar. 2018

🎉2

Sí :)

Gracias
-Blake Niemyjski

El jueves 22 de marzo de 2018 a las 3:57 p. m., Caesar Chen [email protected]
escribió:

La corrección en CoreFx está en PR: dotnet/corefx#28375
https://github.com/dotnet/corefx/pull/28375
—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375454963 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AA-So67a2QfPq72jMHNxaSCBhDXiWXOMks5thBAygaJpZM4SOXLx
.

niemyjski en 23 mar. 2018

¿Hubo alguna razón por la que no pudimos cambiar a HttpClient, que es mucho más rápido?
y más fácil de trabajar? no tendria este problema?

Gracias
-Blake Niemyjski

El viernes 23 de marzo de 2018 a las 7:14, Blake Niemyjski [email protected]
escribió:

Sí :)
Gracias
-Blake Niemyjski
El jueves 22 de marzo de 2018 a las 3:57 p. m., Caesar Chen [email protected]
escribió:
La corrección en CoreFx está en PR: dotnet/corefx#28375
https://github.com/dotnet/corefx/pull/28375
—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375454963 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AA-So67a2QfPq72jMHNxaSCBhDXiWXOMks5thBAygaJpZM4SOXLx
.

niemyjski en 23 mar. 2018

@niemyjski , ¿quiere decir que el cambio de RestSharp usa HttpClient en lugar de HttpWebRequest ?

alexeyzimarev en 23 mar. 2018

Sí :)

Gracias
-Blake Niemyjski

El viernes 23 de marzo de 2018 a las 9:22, Alexey Zimarev [email protected]
escribió:

@niemyjski https://github.com/niemyjski quieres decir que cambias de
¿RestSharp usa HttpClient en lugar de HttpWebRequest?
—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375680769 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AA-So0cbK66_Nq-MRdk0xwdb7sLPSGUoks5thQUUgaJpZM4SOXLx
.

niemyjski en 23 mar. 2018

@niemyjski la pregunta era una _u_ otra, _sí_ realmente no es una respuesta válida :)

Si quiere decir que RestSharp debería usar HttpClient , estoy a favor, pero la última vez que lo intenté fue mucho trabajo hacer coincidir todos los parámetros en RestClient.

alexeyzimarev en 25 mar. 2018

Sí, deberíamos cambiar a HttpClient, que tiene mucha más flexibilidad, mejor rendimiento y una API moderna que sabemos que funciona en todas partes. Podríamos hacer algunos cambios de última hora y superar al mayor :)

niemyjski en 25 mar. 2018

Sí, estoy bien haciendo esto, pero no lo hago solo. Lo intenté y fue demasiado trabajo. También eliminaría las llamadas asíncronas que aceptan devoluciones de llamada. ContinueWith debería estar bien.

alexeyzimarev en 25 mar. 2018

👍1

Parece que esto se ha fusionado con 2.1, ¿deberíamos emitir un nightly que haga referencia a la nueva vista previa de 2 bits y podamos mover otros paquetes por mucho tiempo? ¿Hay alguna solución alternativa que podamos hacer para < 2.1 runtimes/libs?

niemyjski en 20 abr. 2018

no tengo ni idea de soluciones

alexeyzimarev en 20 abr. 2018

Necesito hacer un lanzamiento primero antes de poder cambiar la versión preliminar a la vista previa de referencia 2.1

alexeyzimarev en 20 abr. 2018

¿Se ha resuelto esto? Los paquetes 2.1 rtm están en nuget.

niemyjski en 1 jun. 2018

Entonces, ¿debe intentar usar 2.1 y ver si lo arreglaron?

alexeyzimarev en 1 jun. 2018

@niemyjski mi comentario del 20 de abril es estúpido. No necesito apuntar nada a ninguna parte. La biblioteca compila a .NET Standard 2.0. El error se debe a un error en el tiempo de ejecución de .NET Core 2.0, por lo que tan pronto como reconstruya su aplicación con .NET Core 2.1, si el problema se soluciona, debería comenzar a funcionar. Perdón por la confusión.

alexeyzimarev en 1 jun. 2018

¿Fue útil esta página

0 / 5 - 0 calificaciones