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

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

1 голос
/ 16 апреля 2009

В нашем проекте у нас есть целая куча маленьких файлов 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 сообщает о загрузке из кэша.

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

Ответы [ 3 ]

2 голосов
/ 17 апреля 2009

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

По сути, мне пришлось самому написать логику для установки статуса 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

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

1 голос
/ 19 апреля 2009

@ 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 следующего ресурса

0 голосов
/ 14 мая 2009

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

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

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

...