envoyproxy/envoy

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

Open

#12 374 ouverte le 30 juil. 2020

Voir sur GitHub
 (1 commentaire) (0 réactions) (0 assignés)C++ (5 373 forks)batch import
area/httpenhancementhelp wanted

Métriques du dépôt

Stars
 (27 997 stars)
Métriques de merge PR
 (Merge moyen 8j) (378 PRs mergées en 30 j)

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.

Guide contributeur

Direction de recherche
Examinez la discussion PR associée (#12178) pour comprendre l'approche préférée (option 2 : ajouter des indicateurs end stream à addEncodedData). Ensuite, implémentez les modifications dans le gestionnaire de filtres pour permettre aux filtres de contrôler si les en têtes de fin sont émis, en garantissant la cohérence pour les chemins de données encodées et décodées.
Stack technique
c
Domaine
backendinfrastructure
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
4
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-2 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Ancienne
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
C++Envoy filter pipeline
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
20