spring-cloud/spring-cloud-gateway

Modify Request Body for a GET request

Open

#1 147 ouverte le 3 juil. 2019

Voir sur GitHub
 (7 commentaires) (0 réactions) (0 assignés)Java (3 204 forks)batch import
enhancementhelp wanted

Métriques du dépôt

Stars
 (4 284 stars)
Métriques de merge PR
 (Merge moyen 1j 21h) (18 PRs mergées en 30 j)

Description

We currently have custom code for modifying request body which works but I want to move to the standard ModifyRequestBodyGatewayFilterFactory.

We have a scenario where Spring Cloud Gateway received a GET request and we need call an internal GraphQL api with a POST and a request body.

ModifyRequestBodyGatewayFilterFactory works great if there is a body present in the original request but doesn't apply the rewriteFunction when there is no body on GET requests.

I am using v2.1.2.RELEASE and I have hacked together a change to ModifyRequestBodyGatewayFilterFactory which works for me:

Mono<?> modifiedBody = serverRequest.bodyToMono(inClass)
        .defaultIfEmpty("") //added this line
        .flatMap(o -> config.rewriteFunction.apply(exchange, o));

I appreciate that the ModifyRequestBodyGatewayFilterFactory is beta, but would it be possible to support adding a body for GET requests in the future?

Guide contributeur

Direction de recherche
Examinez l'implémentation actuelle de `ModifyRequestBodyGatewayFilterFactory` dans le dépôt spring cloud gateway. La correction proposée par l'utilisateur consiste à ajouter `.defaultIfEmpty("")` dans la méthode `filter` pour permettre la réécriture du corps lorsque le corps de la requête d'origine est vide (typique pour les requêtes GET). Implémentez ce changement et assurez vous qu'il ne casse pas le comportement existant pour les requêtes POST avec un corps. Écrivez des tests unitaires couvrant les deux scénarios et vérifiez que le filtre fonctionne avec le `ModifyRequestBodyGatewayFilterFactory` standard. Reportez vous à l'issue liée pour un contexte supplémentaire sur le comportement attendu.
Stack technique
javaspring
Domaine
backendapicloud
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.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
Une demi journée
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
JavaGitSpring
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
70