Распределение запросов по доменам - подрывает чрезмерную безопасность

Question

Следуя евангелизации Стива (YSlow) Соудера, мой сайт (LibraryThing.com) распределяет запросы по доменам для облегчения параллельной загрузки. Мы делаем CSS, JS и изображения; Вы также можете использовать Flash и т. д. Мы также используем версию Prototype от Google, которая является междоменной, а не междоменной.

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

Вопрос в том, как лучше всего с этим справиться?

Прямо сейчас, когда он достигает нижней части страницы, мы проверяем, установлена ​​ли какая-либо переменная JS, объявленная в скрипте, который должен был быть загружен. Если он не установлен, он получает его из основного домена и устанавливает файл cookie, чтобы в следующий раз не загружать его из субдомена. Но мы только перезагружаем JS внизу, поэтому, если CSS тоже не работает, вы смотрите на мусор.

У кого-нибудь есть лучшее или более обобщенное решение? Я думаю, что может быть общий сценарий "onload" или "onerror", который устанавливает cookie и загружает содержимое?

Answer 1

Если это поведение всегда затрагивает, по крайней мере, файлы JS, одним из вариантов будет сохранение файла cookie, указывающего, проверялся ли браузер пользователя на это поведение. Если они не были протестированы, вставьте (в качестве первого элемента сценария в теге) ссылку на междоменный сценарий, который просто устанавливает для этого файла cookie «успех». Затем сразу после этого установите встроенный JS, который проверит наличие этого файла cookie, и, если он не установлен, установите значение «fail» и перезагрузите страницу.

Затем на стороне сервера просто проверьте тот же файл cookie и убедитесь, что межсайтовые запросы не отправляются никому с "неудачным" результатом.

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

Answer 2

Я собираюсь сделать несколько диких предположений о вашей проблеме.

Cache. Вносили ли вы эти изменения в файлы сценариев, у этих проблемных пользователей могли быть более старые версии. IE 6 очень плохо работает с чрезмерным усердием кэширования.

Я заметил, что ваши скрипты не содержат build # в URL, XYZ.js? Version = 3 заставит браузер не использовать старые кэшированные скрипты, такие как XYZ.ks? Version = 2. (Относится также к изображениям / CSS)

У вас также есть встроенный JavaScript, смешанный с вашим HTML, который также будет кэширован.

3 домена, скорее всего, излишни, если на вашем сайте нет тонны контента (огромные страницы)

Поиск DNS может быть дорогим и иметь очень большие значения времени ожидания.

Мне было бы неудобно размещать JavaScript моего сайта на отдельном домене из-за возможных конфликтов безопасности. Вы должны синхронизировать вызовы javascript / ajax с доменами. Похоже, больше хлопот, чем стоит.

Я использую i.domain.com и domain.com более 5 лет без проблем.

Могу поспорить, что возвращение JS в основной домен решит ваши проблемы. Это, безусловно, сделает его менее сложным и простым в обращении.

Но все сделано правильно, ваши 3 домена должны работать. К сожалению, у меня недостаточно информации в этом вопросе, чтобы найти проблему.

Answer 3

У вас есть определенный список пользовательских агентов, которые представляют это поведение? Может быть, Apache Conf может решить эту проблему? (или создайте новую проблему для решения :-)).

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

Соудерс тоже об этом говорил, но всегда полезно проверить соотношение количества отправленных / полученных запросов браузерами.