envoyproxy/envoy

hcm: Allow filter to control on emitting trailers (e.g. to skip encoding trailers when empty)

Open

#12.374 aberto em 30 de jul. de 2020

Ver no GitHub
 (1 comment) (0 reactions) (0 assignees)C++ (5.373 forks)batch import
area/httpenhancementhelp wanted

Métricas do repositório

Stars
 (27.997 stars)
Métricas de merge de PR
 (Mesclagem média 8d) (378 fundiu PRs em 30d)

Description

Context: Some of the filters, e.g. gRPC Web requires to skip encoding trailers due to https://github.com/envoyproxy/envoy/issues/10514.

i.e. currently, we have the following "problematic" response frames.

[  5.036] recv DATA frame <length=28, flags=0x00, stream_id=13>
[  5.040] recv DATA frame <length=52, flags=0x00, stream_id=13>
[  5.053] recv HEADERS frame <length=0, flags=0x05, stream_id=13>
          ; END_STREAM | END_HEADERS

What we want is something like:

[  5.036] recv DATA frame <length=28, flags=0x00, stream_id=13>
[  5.040] recv DATA frame <length=52, flags=0x00, stream_id=13>
          ; END_STREAM

We have the current data frames since we always encode trailers. The proposed solution will be to have control from the filter side.

A couple of options:

  1. introduce a new return enum to FilterTrailersStatus, to indicate that trailers should not be emitted.
  2. add end_stream flags to addEncodedData, end stream there and encodeTrailers return StopIteration

From the discussion here, the second of the options above is preferable and when doing that we should do a parallel fix in addDecodedData too.

Guia do colaborador

Direção de pesquisa
Revise a discussão do PR relacionado (#12178) para entender a abordagem preferida (opção 2: adicionar sinalizadores end stream a addEncodedData). Em seguida, implemente as alterações no gerenciador de filtros para permitir que os filtros controlem se os trailers são emitidos, garantindo consistência para caminhos de dados codificados e decodificados.
Pilha de tecnologia
c
Domain
backendinfrastructure
Tipo Issue
Funcionalidade
DifficultyDificuldade de implementação estimada para um novo contribuidor, de 1 para alterações muito pequenas a 5 para trabalho de nível especializado.
4
Tempo estimadoUm intervalo de tempo aproximado para um colaborador experiente investigar, implementar, testar e preparar um pull request.
1-2 dias
Status da atividadeQuão disponível o issue aparece agora: novo, ativo, obsoleto, bloqueado ou aguardando entrada do mantenedor.
Antigo
ClarityCom que clareza o issue explica a mudança esperada, os critérios de aceitação e a próxima etapa.
Claro
Prerequisites
C++Envoy filter pipeline
Simpatia para novatosUma pontuação de 1 a 100 que estima o quão acessível este issue é para colaboradores iniciantes.
20