Мне нравится идея коротких чистых URL-адресов, таких как example.com вместо www.example.com, и, конечно, какой бы из них ни использовался, он должен перенаправлять на другой. Однако, когда я исследовал этот вопрос с течением времени, я пришел к выводу, что использование URL-адреса без www в качестве канонического URL-адреса является помехой, если когда-либо придет время размещать статический контент в отдельном домене без увеличения размера передачи. с печеньем.
Другими словами, если http://example.com - ваш канонический URL-адрес, то, скорее всего, он будет включать файлы cookie. Из-за способа установки файлов cookie эти файлы cookie будут использоваться для всех поддоменов, таких как users.example.com, dev.example.com, www.example.com и, что наиболее важно, images.example.com или files.example .com.
Таким образом, если вы хотите обслуживать статическое содержимое файла из отдельного поддомена, вы в конечном итоге свяжете с ними файлы cookie с основного сайта и увеличите размер передачи HTTP-запроса.
В этом случае, чтобы предотвратить передачу файлов cookie со статическим содержимым, вам нужно будет купить совершенно отдельный URL-адрес (например, examplefiles.com).
И наоборот, если вы установите www.example.com в качестве канонического URL-адреса, я считаю, что файл cookie применяется только к этому www. site, а не на другие поддомены. В этом случае вы избавляетесь от необходимости покупать и поддерживать второй URL-адрес, чтобы избежать обслуживания файлов cookie с вашим статическим содержимым, вы просто убедитесь, что files.example.com или images.example.com или тому подобное настроено на -not- подавать куки.
Верен ли этот анализ? Разве эта проблема не использует короткий URL-адрес без www в качестве вашего канонического URL-адреса, который немного не пригоден для будущего, в этом небольшом, но потенциально важном способе в будущем? Есть ли другие смягчающие факторы, которые мне не хватает, например, метод, гарантирующий, что файл cookie установлен только для канонического короткого URL-адреса без www?
Я не считаю это проблемой, поскольку файлы cookie не такие уж большие и серверу не нужно отправлять их обратно в ответ. Итак, хотя да, один или несколько файлов cookie, установленных example.com, будут "раздувать" запрос на static.example.com, static.example.com не должен отправлять его обратно в ответ, поэтому ответ сервера полностью не затронут .
Кроме того, если у вас есть контент, который, как вы знаете, является статическим (изображения, CSS, JS и т. Д.), Вам следует установить правильные заголовки управления кешем, особенно заголовок Expires на некоторое подходящее время в будущем (например, +1 день, + 1 неделя, +50 лет, независимо от того, как часто меняется ваш статический контент). После этого эти файлы cookie будут отправлены только один раз, а затем будущая потребность в этих файлах будет обрабатываться кешем браузера.
Если вы все еще чувствуете, что это слишком много (честно говоря, я не понимаю, как это могло быть), вы можете смягчить это, используя пути. Например, если вашему веб-приложению нужны только файлы cookie на example.com/app, установите путь для файлов cookie на / app, а затем запросы к static.example.com/images/some-awesome-image.jpg не будут отправлять этот файл cookie, потому что путь не совпадает.
Вы можете еще больше уменьшить его, уменьшив количество используемых файлов cookie - для большинства целей один (и только один) файл cookie, хранящий один идентификатор сеанса, добавляет только несколько байтов (менее 1 КБ в каждой реализации, которую я видел / использовал) , и предоставляет серверу достаточно информации, чтобы найти все, что ему нужно знать об этом клиентском сервере.
Честно говоря, если вы беспокоитесь о том, что домены с короткими URL-адресами делают ваш сайт небезопасным из-за файлов cookie, то я думаю, что у вас есть архитектурная проблема со слишком большим / слишком большим количеством файлов cookie, и вам следует пересмотреть свою стратегию с учетом этого. точка зрения.
Да, ваш анализ верен. Конечно, вы всегда можете выделить изрядные 10 долларов в год на отдельный домен и использовать любое каноническое доменное имя, которое хотите использовать.