Этот баг требует правильности пути. Видимо, исправив(или нет?) его, разработчики упустили противоположный вариант, о котором говорится в топике — проверка не происходит «в случае задания некорректных путей в шаблоне».

А wysiwig-editors-то вам в веб-разработке зачем?

Ваша память изменяет вам с форк-бомбами, видимо, а не с «регекспами», подвешивающими юникс.

Черт, вот что значит сидеть дома ,)
До вашего комментария я свято верил в то, что сегодня действительно пятница

У нас многие приложения пишутся на рельсе, а высоконагруженная часть оборачивается во внутренний закрытый REST-сервис на scala(liftweb).

Имелось в виду ASP.NET mvc

Изредка не догружается тело страницы. Стили и картинки загружаются стабильно.

Всегда быо интересно, из каких соображений имеет значение именно отношение(вх/исх или наоборот) трафика, а не его количество?

Скачивая, вы, как правило, раздаете…

Конечно. В данном продукте это принципиально ненужная функция, потому что авторизация замедлит время ответа.

Ну картинки тоже можно включить в список разрешенных. и js.

хватит уже ставить эти дурацкие теги <sub>// можно хотя бы вот так(_{, <font>)}

Ну опять же — не думаю, что ребята в mozilla не подумали об этом.
Нужно, проверять Content-Length и от этого плясать дальше.

Я уверен, что разработчики браузеров не такие дураки, чтобы префетчить документы с mime-типом, отличным от text/html

Тут разница в трафике геометрическая(если можно так сказать) — не на сколько-то килобайт, а в несколько раз. И это очень существенно и ощутимо в RIA. Тот же gmail — даже в нем раньше было ощутимо время задержки при переходе по пунктам меню.
Сейчас же все происходит очень быстро — там отдается json(довольно своеобразный — почему-то в начале файла с данными стоит while(1);). Если бы каждый элемент списка был обернут в div'ы, p и span, времени на загрузку данных было бы потрачено в несколько раз больше. Да и просто подумать: зачем грузить данные, которые уже были загружены? (html-шаблон)

Вытягивать шаблоны всех данных можно(например, показывать блок статистики по балансу или форму логина), но сами данные в нормально построенном приложении просто не должны иметь шанса туда попасть например, без валидной сессии аутентификации.

Плюсы в итоге имеет сам клиент: по сети передаются только данные json. Отсюда следует более высокая скорость и меньшее потребление трафика.

Все превосходно. Задачи-то там тривиальные решаются при рендеринге шаблонов. Не один проект реализовал с использованием шаблонизаторов. Разные решения пробовал. ejs — самый простой и удобный. Все остальные обладают неоправданным излишеством.
Хочу, кстати, заметить, что вдохновителем ejs является erb — стандартный шаблонизатор в RubyOnRails.

Второй и третий аргументы очень сомнительны )