Incidente: A antiga rotina de randomização de números "Randomize" não seguia o padrão CSPRNG (gerador de número pseudo-aleatório criptograficamente seguro).

Solução: Criado uma nova função Advpl, com nome "Random" para atender a esta nova demanda. Documentação: Random

Incidente: Ao fazer uma requisição pela função HttpPost, onde o post foi submetido para o servidor sem o recebimento de resposta, e ao recuperar o código do erro com o HttpGetStatus, o retorno é zero, com mensagem em branco, dando a falsa impressão que ocorreu com sucesso.

Solução:
Feito um ajuste nos erros genéricos, para retornar codigo 500 e "Internal Server Error" quando não houver uma resposta recebida após o HttpPost.

Chamado: DTAPPSRV-1214

Incidente: ao realizar uma requisição GET, via postman, com o header Content-Type: text/plain, o Appserver ocorre uma exceção

Chamado: DTAPPSRV-1526

Incidente: Ao configurar a DefaultPage de uma location no HTTP Server do Vader, a mesma só é respeitada no diretório raiz do site e não nos seu sub-diretórios.

Solução: Comportamento modificado no Vader, seguindo como por exemplo:

oCfg[aLocations[nY]]['Path'] := "/path"
oCfg[aLocations[nY]]['RootPath'] := "C:\Protheus\Protheus_Data\rootpath"
oCfg[aLocations[nY]]['DefaultPage'] := {"index.html"}

Acesso a diretorios:

http://localhost:8282/path/subdiretorio/index.html
http://localhost:8282/path/subdiretorio/

Chamado: DTAPPSRV-2301

Incidente: Comportamento do connection para HTTP/1.1 que é keep-alive, diferente do HTTP/1.0.

Chamado: DTAPPSRV-2302

Incidente:
Ao atribuir um texto a propriedade ::cBody utilizando += para concatenar a string atual da propriedade, a atribuição não acontece.

Solução:
Foi corrigido a forma que faz a atribuição internamente. Ja tinha sido apresentado um workaround de como fazer a atribuição (fazendo a soma em duas etapas), e foi feito esse comportamento internamente.

Chamado: DTAPPSRV-2543

Incidente:
A execução de queries com a RDD TOPCONN emulada pelo SQLITE (usando RpoDB=SQLITE) e tabela temporária falha, apresentando a mensagem de erro abaixo:

2020-07-06T16:22:54.854000-03:00 13428|[SQLITE ERR] err: 1     no such table: tmp_13428_T1

Solução:
Para permitir este comportamento, da mesma forma que já é suportado pelo TOTVS | DBAccess, fizemos uma correção na camada do SQLITE para que a consulta ocorra no database correto e sob o alias real da tabela temporária.

Chamado: TPGW-233

Incidente: Exibição de mensagens de erro na validação da existência de arquivos.

Solução: Ocultar as mensagens com opção de ativar através de configurações.

Chamado: DTAPPSRV-3226

Incidente:
Ao realizar um calculo com o operador += o retorno era incorreto

Solução:
Realizado tratamentos de arredondamento faltantes no operador em questão

Chamado: DTAPPSRV-2959

Incidente:
Ambientes que utilizam a RDD SQLite apresentavam falha na execução de um DBSeek, dado o uso de índices criados com IndRegua(). Assim, ao fazer um DBSkip(), o desenvolvedor sempre tinha a impressão de estar em EOF.

Solução:
Ajuste na camada do TOTVS | Application Server para evitar este comportamento, equalizando assim, com o comportamento da RDD TOPCONN.

Chamado: DTAPPSRV-3406

Incidente: Ao utilizar uma conversão Hmac utilizando hexadecimal (00), estava fazendo a conversão errada.

Solução: Corrigido o problema de analise de números em hexadecimal.

Chamado: DTAPPSRV-3199

Incidente: Erro na passagem de parâmetro lógico no parâmetro de SSL no método connect da classe tRPC.

Solução: Correção na validação do parâmetro de SSL no método connect da classe tRPC.

Chamado: DTAPPSRV-3011

Incidente: A mensagem com CONNECT enviada para o proxy não era entendida e por isso o proxy retornava código de erro 400 (Bad Request) ao invés de 407 (Proxy Authentication Required).

Solução: Removido caracteres inválidos na mensagem com CONNECT que é enviada para o proxy.

Chamado: DTAPPSRV-2999

Incidente: Arquivos compactados (zip) com senha em Linux não abrem corretamente mesmo informando a senha.

Solução: Atualização da lib minizip que corrige esse problema

Chamado: DTAPPSRV-2901

Incidente:
Ao realizar a chamada do getClientIP, ele esta retornando o ip de loopback e não o ip correto do client.

Solução:
Existia uma inconsistência com a informação do pacote recebido via a porta Multiprotocolo. Foi alterado o pacote de conexão com o ip correto.

Chamado: DTAPPSRV-2792