Каковы плюсы и минусы URL по умолчанию с www или без www? - PullRequest
2 голосов
/ 04 августа 2010

Нам нужно по умолчанию URL для уникального имени.Если это www, то без префикса или наоборот.Таким образом, решение, которое нужно принять, это либо придерживаться www, либо без префикса.

Без префикса cookie устанавливается для всех поддоменов.Каковы другие недостатки этого?Или преимущества?

В основном это нужно для OpenID, поскольку OpenID заставит пользователей выглядеть иначе, если они пришли с www или без префикса.

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

Ответы [ 2 ]

3 голосов
/ 04 августа 2010

Возможно, вы все равно захотите перенаправить (с HTTP 301 - Permanent Redirect) один на другой, так как поддерживать согласованные URL намного проще. Поэтому, что бы вы ни решили, просто убедитесь, что настоящая аутентификация выполнена после перенаправления, и пользователи, выглядящие иначе, не будут проблемой.

Тем не менее, если вы хотите www или нет, полностью зависит от того, как работают другие вещи в вашем приложении. Вы упоминаете, что куки для domain.com будут сохранены для всех поддоменов - это то, что вы хотите? Вам когда-нибудь понадобится провести различие (например, разрешив пользователям настраивать свои собственные системы аутентификации для поддоменов, как это может сделать сервис общего хостинга)?

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

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

2 голосов
/ 04 августа 2010

Если не , используя субдомен www, вы можете потерять производительность при доставке статического контента, как указано здесь: http://developer.yahoo.com/performance/rules.html#cookie_free. Как я понимаю, если вы используете http://example.com/и http://static.example.com для статического содержимого: любые файлы cookie, установленные вами в основном домене, будут передаваться с запросами на ваш статический поддомен.

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

Опять же, это очень незначительный недостаток, и он действительно вступает в игру только тогда, когда вы имеете дело с сайтом с высоким спросом.(Например, Digg использует http://digg.com и http://*.diggstatic.com).

В конечном счете, я бы сказал, что это настолько незначительная проблема, что ее, вероятно, можно решить, если производительность начнет снижаться.Не оптимизируйте преждевременно, и все это ...

И, как указывает @Tomas Lycken, убедитесь, что вы учитываете www, даже если вы не используете поддомен.

...