java.net.URI$match Uri 에 특수문자가 들어가게되면 http protocal을 오갈때 보통 encoding을 통해서 parsing에 문제가 없도록 해주게 됩니다. 하지만 이게 언제부터 생긴 국룰인지 모르겠지만 과거에는 그렇지 않았음을 알게 되었습니다. Legacy client들이 encoding을 하지 않고, 심지어 해킹이 가능할 수 있는 특수문자 '파이프'와 같은 char를 날 것으로 보내오고 있었습니다. 현재 Spring cloud gateway(이하 SCG)를 apigateway로 준비하고 있는 중입니다. 그 과정에서 TC를 통해 해당 이슈가 드러나게 되었는 데, 내용인 즉슨 Netty에서 URI를 검수하면서 특정 특수 문자에 대해서는 그냥 400 Bad gateway를 내려버리는 ..

Reponse body cache Request body에 이어 Response body도 리턴하기 전에 읽어야 하는 요구사항이 나타났습니다. 최우선으로는 구현된 library나 내부 필터가 존재하면 이용하는 방향으로 가려고 했지만 신기하게도 사용빈도가 떨어지는 이유인지 Response body의 경우 만들어진 캐싱 코드가 없는 것 같아보여 직접 구현을 해야했습니다. @Component public class ResponseBodyCheckFilter implements GlobalFilter, Ordered { @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { return chain.filter( ex..

Request body cache Spring cloud gateway를 도입하는 과정에서 backend 로의 routing 전에 request body를 열어보아야하는 요구사항이 있었습니다. 특별히 손을 대지 않는 다면, filter들을 통해서 라우팅을 하는 과정에서 body가 읽혀지게 됩니다. 하지만 rest call에서 body는 상대편에서 보내오는 data stream을 직접 읽어오는 식이다보니 버퍼에 있는 내용을 꺼내게 되면 비게 됩니다. 버퍼에서 두번 읽을 수 없기 때문에 두 곳에서 사용을 하려면 처음 읽은 데이터를 어떤 식으로든 보존해 두었다가 재사용을 해야합니다. Spring cloud gateway에는 이를 cache를 통해서 해결하게끔 filter가 만들어져있고, 실제 사용하는 방법을 ..