Узелки на память...

Задача: на сайте используется набор javascript-библиотек, которые сливаются php-скриптом в один файл с названием вида 78472581267468236825748923.js (где цифры - имплод номеров версий каждой отдельной библиотеки), а контент оптимизирован и (может быть) как-то упакован. Планируется, что сий файл будет сидеть в кеше (а по размеру он довольно большой) и когда версия хоть одной из библиотек изменится - изменится имя файла и он будет заново запрошен с сервера. Все счастливы, траффик сэкономлен, дети смеются, Санта Клаус раздаёт подарки, мир во всём мире.

Как же дело обстоит на самом деле? В один прекрасный момент вы замечаете, что траффик у вас совсем не убавился и посмотрев статистику обнаруживаете, что ваш файлик с красивым именем 78472581267468236825748923.js таскается с сервера при каждом запросе и ну никак не хочет залезать в кеш браузера.

Начинаем копать глубже и при сравнении хедеров нашего файла и обычного статичного js обнаруживаем, что у последнего в хедере присутствует параметр "Last-Modified: Wed, 10 Sep 2008 07:01:14 GMT", определяющий дату обновления файла. В нашем же файле параметр сий отсутствует и сервер каждый раз шлёт ответ клиенту "200 ОК" с полным контентом.

Гуглим. Пишем принудительную отправку этого параметра в хедере. Не шлётся и всё - хоть убейся.

На различных форумах в сети есть много логичных объяснений. Например, "хренли слать дату обновления скрипта, если контент динамический?" (действительно, возразить сложно).

Грешил сначала на апач (думал, он отправляемые мной хедеры парсит и пропускает только то, что ему угодно).

Попробовал активировать для моего файла xBitHack. Появились первые подвижки - в хедере возник "Last-Modified", однако, ссылался он на текущую дату/время и изменениям не поддавался.

Потом думал, что пхп не хочет мои хедеры отдавать. 10 раз проверил все возможные варианты синтаксиса, генерацию даты, генерацию хеш-ключа ETag - ноль реакции.

В конечном итоге была найдена информация, что апач будет отдавать Last-Modified только если у файла есть разрешение на execute для группы. Для chmod пришлось тоже писать скриптик, т.к. ходим к хостеру самбой.

И, о чудо, вдруг всё заработало! )))

 Механизм определения обновления через хеш ETag описывать не буду - он будет в первой 10 выдачи в гугле по запросу "etag".

Безумное 3 вчера отмечал 100 ревижн. Всего сотый, потому, что на работе в репозиторий сливать нет возможности (он на домашнем компе), и поэтому наработки с офисного компа раз в 2-3 дня сливаются на домашний, мержатся и закидываются в свн.

На сегодняшний день готово примерно 55% от запланированного объёма.

В принципе, это уже довольно работоспособный продукт, но запускать его ещё рано.

http://www.awd.ru/tip.htm - читал всё утро. Офигенно!

P.S. Узнал новое слово - impassable.

Английский художник Бенедикт Радклифф создал эту невероятную скульптуру Тойоты Короллы в натуральную величину, используя только проволоку. Выглядит как компьютерный макет, но она настоящая!

via

(Под катом) ещё несколько фоток.

Несколько интересных "открытий" было совершено в борьбе за кроссбраузерность клиентской части нового чата. Два дня жесткого секса с кодом и гуглом выявили мои глубокие чувства к ослобраузерам ИЕ. В двух словах:

Задача: надо создать группу радиобатонов и поместить их в контейнер в документе.

Решение: тривиальное

 for (var i=0; i<5; i++){
   var rb = document.createElement("input");
   rb.type = "radio";
   rb.name = "group1";
   holder.appendChild(rb);
 }

всё хорошо и красиво, все плачут от счастья... пока в голову не приходит мысль на наши радиобатоны покликать. В ИЕах не кликается. Ваще.
Перекапывается код на предмет неточностей, несоответствия стандартам - всё вроде правильно. Поиски в гугле выявляют, что наш ненаглядный осёл, оказывается, не может некоторым динамически создаваемым элементам задавать name. Многие даже советуют забивать хер на DOM и херачить всё в innerHTML. 

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

 ...
 try {
   result = document.createElement("<input type='radio' name='group1'>");
 } catch (e) {
   result = document.createElement("input");
   result.type = "radio";
   result.name = "group1";
 }
 ...

Ну из других мелких сюрпризов обнаружилось так же, что в Opera, оказывается, у document есть свойство all, что делает не логичным определение ослобраузеров по if (document.all) {/* some IE code */}.

Так же, хоть многие и утверждали, что в стандартах нет обработчиков события onload для img, обработчики всё-таки есть:

 var img = new Image();
 img.onload = OnLoadHandler;
 img.src = "/path/to/image.jpg";
 
 function OnLoadHandler(e) {
   /* Image loaded */
 }

Тут тоже есть интересные особенности:

1. задавать обработчик события необходимо раньше свойства src, т.к. в противном случае он не сработает, если картинка найдена в кеше (не уверен, возможно только для нашего любимого ИЕ);

2. не-ИЕ-браузеры передают в обработчик события параметр e (собственно наше событие), в котором есть ссылка на объект, породивший событие - e.currentTarget. Для ослобраузера сие не верно и надо брать window.event. В случае с картинками - в ИЕ оба параметры, увы, пусты, поэтому, чтобы определить, какая именно из картинок догрузилась, можно использовать задание ссылки на обработчик вида:

 img.onload = function() {OnLoadHandler(this);}

Тогда в обработчик нам придёт сама картинка.

Ещё какие-то были интересности, но я уже не помню. Вспомню - напишу %)