я не занимаюсь детсвом. XML куда удобней. К тому же есть куда более эффективные способы, особенно для гугла...
это уже не очень хорошо, согласны?
Чистыее HTTP, имхо конечно, мало кому нужны, вернее может и нужны, но платить будут врятле. Легче наплодить свои...
тогда просто забейте... или, что правильней, просто вставьте кусок кода, котрый проверяет урл, и если на конце есть/нет слеша делает редирект на нет/есть (как больше нравится)
если нет сложных рерайтов, тогда объясните, по этим ссылкам отдаются разные страницы или одинаковые?
без обид. Вопрос глуп не в вашем посте, а просто в сути....
не стоит ничего мудрить. нет такого понятия как привала по джумли или еще по какмнить граблям. Так уж вышло, что в инете есть одно правило - правило *NIX. Если в пути в конце стоит / - это каталог, если нет - это файл. если бы сайт был нормальным (без кривых CMS) то проблем бы просто небыло. url _http://xxxx/aa - отдавался бы файл aa, а по url _http://xxxx/aa/ отдавался бы файл, установленный в настройках сервера как дефалтовый для папки. И никаких бы разногласий небыло. Разночтения возникают в кривых CMS с использованием километровых правил в модреврайте. Просто приведите правила в соотвествие со стандартом и небудет больше подобных глупых вопросов.
что касается яши... вспомните о панятии дубля (копии) страницы.....
вопросы:
1. Какой тип прокси обсуждается (http/https/ftp/smtp)?
2. Забаненых где? (яша/гугл не обсуждается, ибо мало верю в извращенцев, которые по сей день парсят выдачу таким топором)
3. Как проверяется анонимность прокси?
4. Какой регион проксей?
чтобы небыло криков, что на серваке лежи 20-30 дохлых сайтов на WP, а сервак уже не тянет....
верно. Но задач, где это нужно - очень мало. Чтобы сформировать страницу для юзера, совсем не обязательно делать 10-50 запросвов к БД как в WP или до 70 как в джумле. Можно просто взять файл шаблона и "скрестить" его с файлом данных, в 90% случаев, статических.
БД на файлах, вернее, на основе файловой системы - штука весьма удобная для задачь, где не нужны сложные запросы и выборки. Чтобы она стала эффективной, нужно четко понимать саму задачу и не пытаться залесть туда, где "бинарный" подход SQL просто эффективней. Для CMS (обычные сайты, без сложных структрр данны) и форумов, безусловно, текстовые файлы удобней, проще, надежней, быстрее. В этом есть одно "но". Если все это облочить в шкурку, типа фреймворка, то все плюсы станут минусами... Прелесть прямой работы с файловой системой в скорости и минимизации проверок и ожиданий. Поэтому, хотите получить бычтрый инструмент, просто сделайте 5-10 удобных, заточенных под свою задачу функций и пользуйтесь. Не идити по стопам универсальности. Универсальность (ведь ее программисты придумали для облегчения своей работы), почти всегда, идет в простивовес скорости и качества для конечного пользователя.
можно хоть какие-то данные?
1. Что за сервер.
2. тип серверного ПО.
3. Колическтов сессий в момент тормозов.
это решение других задач, чащще всего, связанных именно с трафиком.
это нагрузка не на сервер а на канал связи. Какой у Вас?
T.R.O.N добавил 31.08.2009 в 11:43
такое имеет смысл тольок на асинхронных каналах. Не думаю что сервак стоит на ADSL или подобном
да, именно об этом валидатор и пишет.
Для остального - уберите все скрипты со страницы или закоментрируте их, дабы валидатор работал с чистым HTML
loed, вы всуньте в валидатор хотябы то что написали!
