Ловушки при использовании Response.Filter

ASP.NET позволяет через свойство HttpResponse.Filter выполнять манипуляции с контентом перед отправкой его клиенту. Под контентом понимается html-разметка, css-стиль, js-код и вообще любые данные, отправляемые веб-сервером в ответ на запрос. Для чего это нужно? Например, для замены в теле ответа одного текста на другой. Подробно расписывать как это делать я не буду, а покажу очень важные особенности, которые необходимо учитывать при реализации продобного рода фильтров.

Первая ловушка — отдаваемый сервером контент разбивается на порции. Приведу типичный код, встречающийся на просторах интернета, который заменяет текст:

public class HtmlFilter : Stream
{
    // Второстепенный код пропущен.

    //  Основной метод, производящий замену текста перед записью в поток.
    public override void Write(byte[] buffer, int offset, int count)
    {
        Encoding encoding = HttpContext.Current.Response.ContentEncoding;

        string s = encoding.GetString(buffer);
        
        s = Regex.Replace(s, pattern, replacement);
        
        byte[] outData = encoding.GetBytes(s);
        
        _baseStream.Write(outData, 0, outData.Length);
    }
}

Чем примечателен этот код? Тем, что он неправильный. Контент разбивается на порции, и эти порции записываются в поток по отдельности — метод Write() вызывается несколько раз. Это значит, что иногда в отфильтрованном контенте будут присутствовать незаменённые экземпляры искомого текста, которым "посчастливилось" попасть на границы порций, а значит Regex просто не найдёт и не заменит их. Самое плохое в этой ошибке то, что она выглядит как случайная, её очень сложно воспроизвести. Вероятность её проявления прямо пропорционально величине заменяемого текста (pattern'а). Чем он больше, тем вероятней то, что он окажется на границе порций контента. В моём случае заменяемый текст являлся частью URL, и мне даже удалось увидеть один "неправильный" URL.

Окей, как же тогда правильно заменять текст в контенте? Основной принцип — склеивать порции, потом анализировать их вместе, и после этого писать в поток и отсылать. На эту тему есть замечательный пост Рика Страла (Rick Strahl). Он реализовал удобный класс-фильтр, который решает эту проблему.

Вторая ловушка существует при фильтрации статического контента. Если включено сжатие статических файлов, IIS помещает сжатые статические оригинальные файлы в свой кэш. При последующих запросах IIS сразу отдаст файл из кэша, минуя потоковый фильтр. Выглядит это так: при первом запросе к статическому файлу возвращается содержимое файла с произведённой обработкой. При дальнейших запросах возвращается уже оригинальное содержимое, потому что взято оно из кэша. Побороть это можно отключением сжатия статического контента.