요청과 응답 파이프라인

요청은 줄지어 놓인 것들을 지나갑니다

1.2에서 builder.Build() 뒤에 놓는 것들을 미들웨어라고 불렀습니다. 요청이 들어오면 등록한 순서대로 그것들을 하나씩 지나가고, 마지막에 우리가 적은 처리 코드에 닿습니다.

중요한 것은 돌아오는 길도 있다는 점입니다. 미들웨어는 다음으로 넘기고 나서 그 아래가 모두 끝난 뒤에 다시 실행할 코드를 둘 수 있습니다. 그래서 미들웨어 하나는 요청을 두 번 만납니다. 들어갈 때 한 번, 나올 때 한 번입니다.

다음으로 넘기지 않을 수도 있습니다. 그러면 그 아래는 아예 실행되지 않습니다. 인증이 실패했을 때 본문을 만들지 않고 곧바로 401을 돌려주는 것이 이 방식입니다.

순서를 직접 보기

ASP.NET Core 의 미들웨어는 다음 처리기를 받아 새 처리기를 돌려주는 함수입니다. 그것을 겹쳐 감싸면 파이프라인이 됩니다. 아래는 그 부분만 떼어 낸 것이라 서버 없이도 돌아갑니다.

var pipeline = new List<Func<Handler, Handler>>();

void Use(Func<Handler, Handler> middleware) => pipeline.Add(middleware);

Use(next => async path => {
    Console.WriteLine("기록 : 들어갑니다");
    await next(path);
    Console.WriteLine("기록 : 나옵니다");
});

Use(next => async path => {
    if (path == "/admin") { Console.WriteLine("인증 : 막았습니다"); return; }
    Console.WriteLine("인증 : 통과");
    await next(path);
});

Handler last = path => { Console.WriteLine("본문 : " + path); return Task.CompletedTask; };

// 뒤에서부터 감쌉니다. 그래야 먼저 등록한 것이 바깥이 됩니다.
Handler app = last;
for (var i = pipeline.Count - 1; i >= 0; i--) app = pipeline[i](app);

await app("/");
Console.WriteLine();
await app("/admin");

delegate Task Handler(string path);

코드는 고쳐서 실행해 볼 수 있습니다. 처음 누를 때만 실행기를 내려받느라 잠시 걸립니다. 적은 코드는 서버로 나가지 않습니다.

두 가지가 보입니다. 기록은 들어갈 때와 나올 때 두 번 찍혔고, /admin 에서는 본문이 아예 실행되지 않았습니다. 그런데도 기록의 "나옵니다" 는 찍혔습니다. 인증이 넘기지 않아도 그보다 바깥에 있는 것은 제 몫을 마칩니다.

실제 코드에서는 이렇습니다

위와 같은 것을 ASP.NET Core 로 적으면 아래가 됩니다. path 자리에 HttpContext 가 오고, 다음 처리기는 next 로 넘어옵니다. 찍히는 순서는 위와 같습니다.

var app = builder.Build();

app.Use(async (context, next) => {
    Console.WriteLine("기록 : 들어갑니다");
    await next();
    Console.WriteLine("기록 : 나옵니다  상태 " + context.Response.StatusCode);
});

app.Use(async (context, next) => {
    if (context.Request.Path == "/admin") {
        Console.WriteLine("인증 : 막았습니다");
        context.Response.StatusCode = 401;
        return;
    }
    Console.WriteLine("인증 : 통과");
    await next();
});

app.MapGet("/", () => "안녕하세요.");

app.Run();

이 코드는 서버가 있어야 하므로 브라우저에서 실행할 수 없습니다. 위의 예제가 같은 일을 합니다.

Use · Run · Map

파이프라인에 무언가를 놓는 방법이 셋입니다.

순서가 곧 동작입니다

미들웨어는 적은 순서대로 실행되므로, 순서를 바꾸면 동작이 바뀝니다. 자리를 잘못 두어도 컴파일 오류가 나지 않기 때문에 돌려 봐야 압니다. 아래가 일반적인 차례입니다.

app.UseHttpsRedirection();   // http 로 오면 https 로 보냅니다
app.UseStaticFiles();        // 파일이면 여기서 끝냅니다(아래로 안 갑니다)
app.UseRouting();            // 어느 코드가 맡을지 정합니다
app.UseAuthentication();     // 누구인지 봅니다
app.UseAuthorization();      // 할 수 있는지 봅니다
app.MapControllers();        // 맡은 코드를 부릅니다

UseAuthorization 이 UseAuthentication 보다 앞서면 누구인지 모르는 채로 권한을 봅니다. 로그인한 사람도 거절당하는데, 오류는 나지 않아 원인을 찾기 어렵습니다.

나오는 길에서는 늦은 것이 있습니다

돌아오는 길에 코드를 둘 수 있다고 해서 무엇이든 할 수 있는 것은 아닙니다. 응답은 머리글이 먼저 나가고 본문이 뒤따릅니다. 본문이 나가기 시작하면 머리글은 이미 보낸 뒤라 고칠 수 없습니다.

app.Use(async (context, next) => {
    await next();
    context.Response.Headers["X-Late"] = "늦었습니다";
});

그런데 브라우저는 200을 받습니다. 응답이 이미 나간 뒤에 발생한 예외라 돌려줄 곳이 없기 때문입니다. 화면은 멀쩡한데 서버 기록에만 예외가 쌓이는 자리이므로, 나오는 길에 응답을 손대는 코드는 조심해서 두어야 합니다.

머리글을 꼭 붙여야 한다면 본문이 나가기 전에 붙이거나, OnStarting 으로 나가기 직전에 부를 코드를 등록합니다.

app.Use(async (context, next) => {
    context.Response.OnStarting(() => {
        context.Response.Headers["X-Early"] = "제때";
        return Task.CompletedTask;
    });

    await next();
});

UseRouting 을 적지 않아도 되는 까닭

직접 해보기