KamoCRM

/imaging/download responde seus bytes novamente em vez de 500 (SITP TP13)

FixDocsService
Navios
18 de outubro de 2026 às 18:03 UTC
Autor
Kamo
Enviar
68ccc05

Desde d1a8762 o corpo de download era um StreamingResponseBody dentro do método RespostaEntity<?>. Spring entrega um StreamingResponseBody para seu gerenciador de streaming apenas quando o tipo de retorno declarado nomeá-lo; como um corpo wildcard foi para os conversores de mensagens, nenhum dos quais escreve um lambda, então cada download através de MVC respondeu 500 "Nenhum conversor para ... com Tipo de Conteúdo pré-definido" (encontrado quando o anexo do Plano de Ferramentas envia documento). O corpo é agora um InputStreamResource sobre o fluxo de objetos MinIO, que ResourceHttpMessageConverter copia em pedaços e fecha: ainda nunca manteve inteiro. Um teste MockMvc fixa os bytes através da pilha MVC real; falha no código antigo.

Todas as alterações

Como o que vês no transporte?

Tudo isso chega em seu espaço de trabalho por conta própria. Comece no plano gratuito e leia esta página novamente em um mês.

Começar Livre Para SempreVer Preços