Заставить браузер кэшировать запрос к действию Castle MonoRail?

Question

В нашем проекте у нас есть целая куча маленьких файлов css/js, поэтому, когда мы создаем представления, мы пишем много <link> или же <script> теги, заставляющие браузер делать много запросов на наш контент CSS / JS. Чтобы исправить это, мы начали искать способ передачи сервером всего одного запроса, который сбрасывает каждый файл css или каждый файл js, связанный с действием, в ответ.

Не вдаваясь в подробности, мы создали класс Helper, который принимает файлы, объединяет их и отображает тег следующим образом:

<script type="text/javascript" src="/content/js15628453.rails"></script>

Затем ContentController имеет действие по умолчанию, которое использует 'js15628453', чтобы найти, где Помощник сохранил объединенный файл и выдает его. Это работает очень хорошо.

Однако, как сообщает Firebug, браузер всегда отправляет запрос в "/content/js15628453.rails", чтобы получить объединенный файл, несмотря на то, что URL-адрес всегда одинаков, а ответ всегда одинаков. Я перепробовал все типы комбинаций HTTP Cache-Control, Expires, Last-Modifiedи т. д. заголовки, но еще не получили что-то, что Firebug сообщает о загрузке из кеша.

Почему браузер может игнорировать эти заголовки? Есть ли другие варианты, которые я могу попытаться заставить кэшировать?

Answer 1

Ну, я понял это, так что в интересах тех, кто может найти это в поисковой системе, я пойду дальше и дам ответ на свой вопрос.

По сути, мне пришлось написать логику для установки статуса 304 самостоятельно:

DateTime lastModified = // some date
string ifModifiedSince = Request.Headers["If-Modified-Since"];
if ( ifModifiedSince != null )
{
    var requestDate = DateTime.Parse( ifModifiedSince );
    if ( requestDate <= lastModified )
    {
        CancelView();
        Response.StatusCode = 304;
        return;
    }
}

Response.CachePolicy.SetLastModified( lastModified );

// Logic to write the file to the OutputStream

Я неправильно предположил, что браузер будет просто использовать свою кэшированную копию, если она существует и срок ее действия не истек, тогда как ему, очевидно, нужно спросить сервер, является ли его кэшированная копия все еще действительной.

Answer 2

@Tinister: Ну, на самом деле то, что вы делаете, это имеете дело с условным GET. То есть - когда запрос Get переходит от клиента к серверу с вопросом "есть ли у вас что-то новее, чем X", а сервер говорит 304, если нет. вы избегаете сервера, генерирующего js, и трафика js-контента, однако стоимость запроса (то есть отправка http-запроса от браузера к серверу) все еще остается. этот материал обрабатывается заголовками Last-Modified/IfMOdifiedThen (один для ответов, один для запросов) и / или заголовком ETAG.

Кэширование - это совсем другое - браузер решает вообще не отправлять запрос GET. он управляется заголовком "Expires" или заголовком Cache-control.

у вас может быть где-то настраиваемый заголовок Cache-Control, и это заставляет клиента игнорировать "Expires". Попробуйте установить "max-age 3600" или что-то в этом роде, и посмотрите, кэшируется ли запрос (забудьте о FB - вместо этого установите точку останова или войдите на сервер, чтобы быть уверенным, что он не вызывается)

сказав, что при работе с файлами js / css вам может не потребоваться фактическое кэширование. это потому, что если браузер решит кэшировать, скажем, на неделю, то вы не сможете заставить его перезагрузить новую версию. поэтому, если вы развернете новую версию на сервере, клиент не увидит ее до тех пор, пока не пройдет неделя, независимо от того, каково новое время (oe etag) нового ресурса - потому что он никогда даже не выдаст условный запрос GET,

Одним из решений (если вы действительно хотите избавиться от предубеждений в сети) является настройка кэширования на максимальное время (скажем, год), а при изменении ресурса вы изменяете URI (как есть - добавляете произвольное значение строки запроса). это заставит браузер перезагрузить новый ресурс js и никогда больше не беспокоить сервер, по крайней мере, до следующего обновления + следующий URI ресурса

Answer 3

Я заметил, что по крайней мере Firefox, похоже, использует штамп "последней модификации" из первоначального запроса при расчете, если он даже обрабатывает HEAD-запрос для проверки "немодифицированного" (304) кода ответа.

Наличие действительно старой отметки времени "последней модификации", по-видимому, приводит к тому, что она не проверяет наличие каких-либо новых версий файла, если это явно не требуется.

Однако я бы не стал сильно полагаться на это.