Restsharp: a porta está sendo removida do cabeçalho do host

Criado em 21 fev. 2018 · 35Comentários · Fonte: restsharp/RestSharp

Comportamento esperado

Restsharp deve enviar o cabeçalho do Host como está sem modificar a porta no valor do cabeçalho do Host.
https://github.com/minio/minio-dotnet/pull/212 está trazendo Restsharp 106.2.1 em vez de Restsharp.Netcore (versão não oficial com suporte a .netcore). No entanto, encontramos erros de incompatibilidade de assinatura porque o autenticador personalizado em uso pelo minio dotnet sdk cria assinatura de autorização usando ip:port como valor para o cabeçalho "Host". Restsharp httpclient parece estar removendo a porta, pois o rastreamento do servidor mostra apenas ip no valor do cabeçalho do host.

Comportamento real

port está sendo retirado do valor do cabeçalho "Host" no Restsharp 106.2.1

Etapas para reproduzir o problema

clone minio-dotnet sdk e obtenha o patch https://github.com/minio/minio-dotnet/pull/212
➜ minio-dotnet git:(02cbcb5) ✗ dotnet restore;dotnet build
➜ minio-dotnet git:(02cbcb5) ✗ dotnet run --project SimpleTest
2.
3.

Especificações

Versão: 106.2.1
Plataforma: Linux/Windows
Subsistema:

StackTrace

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

Fonte

poornas

Comentários muito úteis

Vamos aumentá-lo!

niemyjski em 22 mar. 2018

👍4

Todos 35 comentários

Existe alguma maneira de reproduzi-lo em um teste simples?

alexeyzimarev em 24 fev. 2018

https://github.com/poornas/restsharp-test - este é um projeto básico usando restsharp para fazer uma chamada de lista de buckets para o servidor minio. Ele usa um autenticador personalizado - você verá que ele falha devido à incompatibilidade de assinatura. uma vez que a solicitação é passada para o restsharp, a porta é removida antes de ser passada para o servidor.

poornas em 26 fev. 2018

Obrigado. Vou dar uma olhada e tentar consertar.

alexeyzimarev em 26 fev. 2018

👍2

Obrigado!

niemyjski em 27 fev. 2018

@alexeyzimarev Alguma idéia sobre o que poderia estar causando isso?

niemyjski em 28 fev. 2018

@alexeyzimarev , você já teve a chance de investigar isso? Obrigado

poornas em 5 mar. 2018

Verificando agora

alexeyzimarev em 5 mar. 2018

Eu clonei seu repro e vejo isso:

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

Você quer dizer que os parâmetros na solicitação estão corretos, mas o valor não está sendo enviado corretamente ao servidor?

alexeyzimarev em 5 mar. 2018

@alexeyzimarev , está correto - o rastreamento que você vê acima é antes de chamar executeAsync. Quando ExecuteAsync é chamado, Restsharp invoca o método Authenticate, onde estamos definindo o cabeçalho de autorização de assinatura com base em url:port no autenticador personalizado. port parece ser removido pelo Restsharp antes de atingir o servidor e após a chamada Authenticate().

poornas em 5 mar. 2018

Alguma atualização sobre isso? Estamos bloqueados bastante nisso.

niemyjski em 14 mar. 2018

Desculpe, não consegui ver isso ainda. Se for muito crítico, pode ser que vocês possam passar uma hora depurando-o?

alexeyzimarev em 14 mar. 2018

Eu dei uma olhada rápida nisso. Tanto quanto eu posso dizer, o problema aqui não é realmente com RestSharp, mas na verdade é HttpWebRequest em System.Net !

No momento em que RestSharp entregou a solicitação ao System.Net, a propriedade Host (Uri) no HttpWebRequest ainda contém as informações da porta. No entanto, quando .SendRequest() é chamado, o cabeçalho Host usado é preenchido apenas pelo URI Host, não pelo host e pela porta .

Aqui está uma captura de tela do meu depurador no link acima.
screen shot 2018-03-22 at 11 22 52 am

Isso claramente vai contra a especificação HTTP que respeita o uso de portas.

Alguém por favor me corrija se eu estiver errado, porque eu nunca encontrei um bug no dotnet framework, e geralmente quando eu acho que eu encontrei - eu não encontrei. Caso contrário, suponho que os próximos passos seriam levantar esse problema no repositório CoreFX?

twgraham em 22 mar. 2018

Vamos aumentá-lo!

niemyjski em 22 mar. 2018

👍4

Feito - vamos ver se isso é legítimo onde o bug está ou não.

twgraham em 22 mar. 2018

Apenas curioso - alguém sabe se é uma regressão com recente .NET Core? (2.1) Ou com o último estável (2.0)? Ou diferença de .NET Framework vs. .NET Core, ou diferença entre SO Windows vs. Linux? ("não sei" é uma boa resposta, obrigado!)

karelz em 22 mar. 2018

@karelz TBH eu olhei para este problema para resolver outro problema para que eu pudesse parar de receber avisos do compilador 😆 para mim é um "não sei", eu só tentei isso no .NET Core 2.0 no MacOS. Essa biblioteca apenas recentemente (talvez meses) foi atualizada para oferecer suporte ao .NET Core sobre apenas o .NET Framework. Talvez @alexeyzimarev saiba mais?

twgraham em 22 mar. 2018

OK, pelo menos você já sabe: Funciona no .NET Framework (Windows) e falha no .NET Core 2.0 (Mac). Esse resumo está correto?

karelz em 22 mar. 2018

Não - de outros threads em que estou, eu diria que falha em todas as plataformas no .NET Core 2.0 e não conheço o .NET Framework.

twgraham em 22 mar. 2018

@karelz eu diria que essa suposição estaria correta. Acabei de mudar de framework completo para .net core/standard e então os testes falharam. Não tenho certeza se é uma regressão de 1.x, pois apenas tentamos migrar para o padrão .net 2.0

niemyjski em 22 mar. 2018

👍1

@niemyjski obrigado pela confirmação. Isso é informação suficiente neste momento. Eu estava apenas explorando fatos/experiências conhecidas.

karelz em 22 mar. 2018

Estamos mantendo este assunto em aberto?

alexeyzimarev em 22 mar. 2018

A correção no CoreFx está no PR: https://github.com/dotnet/corefx/pull/28375

caesar-chen em 22 mar. 2018

🎉2

Sim :)

Obrigado
-Blake Niemyjski

Em qui, 22 de março de 2018 às 15h57, Caesar Chen [email protected]
escreveu:

A correção no CoreFx está no PR: dotnet/corefx#28375
https://github.com/dotnet/corefx/pull/28375
—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375454963 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AA-So67a2QfPq72jMHNxaSCBhDXiWXOMks5thBAygaJpZM4SOXLx
.

niemyjski em 23 mar. 2018

Houve algum motivo para não podermos mudar para HttpClient, que é muito mais rápido
e mais fácil de trabalhar? Não teria esse problema?

Obrigado
-Blake Niemyjski

Em sex, 23 de março de 2018 às 7h14, Blake Niemyjski [email protected]
escreveu:

Sim :)
Obrigado
-Blake Niemyjski
Em qui, 22 de março de 2018 às 15h57, Caesar Chen [email protected]
escreveu:
A correção no CoreFx está no PR: dotnet/corefx#28375
https://github.com/dotnet/corefx/pull/28375
—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375454963 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AA-So67a2QfPq72jMHNxaSCBhDXiWXOMks5thBAygaJpZM4SOXLx
.

niemyjski em 23 mar. 2018

@niemyjski você quer dizer que você muda de RestSharp usa HttpClient em vez de HttpWebRequest ?

alexeyzimarev em 23 mar. 2018

Sim :)

Obrigado
-Blake Niemyjski

Em sex, 23 de março de 2018 às 9h22, Alexey Zimarev [email protected]
escreveu:

@niemyjski https://github.com/niemyjski você quer dizer que você muda de
RestSharp usa HttpClient em vez de HttpWebRequest?
—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375680769 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AA-So0cbK66_Nq-MRdk0xwdb7sLPSGUoks5thQUUgaJpZM4SOXLx
.

niemyjski em 23 mar. 2018

@niemyjski a pergunta era uma _ou_ outra, _sim_ realmente não é uma resposta válida :)

Se você quer dizer que RestSharp deve usar HttpClient - eu sou profissional nisso, mas da última vez que tentei, deu muito trabalho para corresponder a todos os parâmetros no RestClient.

alexeyzimarev em 25 mar. 2018

Sim, devemos mudar para HttpClient que tem muito mais flexibilidade, tem melhor desempenho e uma API moderna que sabemos que funciona em todos os lugares. Poderíamos fazer algumas mudanças de última hora e aumentar o principal :)

niemyjski em 25 mar. 2018

Sim, eu estou bem fazendo isso, mas eu não faço isso sozinho. Tentei e deu muito trabalho. Eu também removeria as chamadas assíncronas que aceitam retornos de chamada. ContinueWith deve estar bem.

alexeyzimarev em 25 mar. 2018

👍1

Parece que isso foi mesclado no 2.1, devemos emitir um nightly que faz referência à nova visualização de 2 bits e podemos mover outros pacotes por muito tempo? Existe alguma solução que podemos fazer para < 2.1 runtimes/libs?

niemyjski em 20 abr. 2018

Eu não tenho nenhuma idéia sobre soluções alternativas

alexeyzimarev em 20 abr. 2018

Preciso fazer um lançamento antes de poder alterar o pré-lançamento para a visualização de referência 2.1

alexeyzimarev em 20 abr. 2018

Isso foi resolvido? Os pacotes 2.1 rtm estão no nuget.

niemyjski em 1 jun. 2018

Então, você precisa tentar usar o 2.1 e ver se eles consertaram?

alexeyzimarev em 1 jun. 2018

@niemyjski meu comentário de 20 de abril é estúpido. Não preciso apontar nada para lugar nenhum. A biblioteca compila para o .NET Standard 2.0. O erro é causado por um bug no tempo de execução do .NET Core 2.0, portanto, assim que você reconstruir seu aplicativo com o .NET Core 2.1, se o problema for corrigido, ele deverá começar a funcionar. Desculpe a confusão.

alexeyzimarev em 1 jun. 2018

Esta página foi útil?

0 / 5 - 0 avaliações