Блог на SuperHosting.BG

8сеп/11

Хитрини с .htaccess файла – част 1

Съвети от support- aДойде ред на новата „порция“ от нашите „Съвети от support- a“. :) Както вече знаете, целта на тази категория е да получавате професионално мнение и полезна информация от вашата хостинг компания СуперХостинг.БГ. Не малко са въпросите ви за .htaccess файла. По тази тема има много какво да се каже... Вече е факт първата от поредицата публикации, в които колегите ще споделят интересни решения и казуси, с които се сблъскват ежедневно. Надяваме се така да ви помогнем в опознаването на възможностите, които дава .htaccess файла. Споделяйте и вие интересни моменти от вашата практика!

В следващите редове нашия колега Алекс от отдел Техническа поддръжка посочва каква настройка е необходима и какво трябва да съобразите, така че основният домейн в акаунта ви да зарежда съдържание от друга, желана от вас поддиректория.

На нашите сървъри за споделен хостинг като глобална настройка е зададено, основния домейн на всеки акаунт да зарежда съдържание от /public_html директория - основна директория (Document Root). След голямото увеличение на Add On домейните, клиентите ни питат как да променят основната директория за конкретния акаунт, без това да променя URL адреса, на който се достъпва сайта. Тъй като това е настройка, зададена в конфигурацията на самия сървър, не е удачно да бъде променяна само за дадения акаунт. В този случай, с колегите съдействаме да се извършат желаните промени на ниво акаунт чрез Rewrite правилата в .htaccess файла.

Пример за подобна ситуация е, когато в даден хостинг акаунт има добавени голям брой Add-On домейни. По подразбиране отделните Add-On домейни се създават с Document Root - поддиректория на /public_html. Клиента желае и основния домейн да зарежда съдържание на поддиректория на /public_html за по-лесно управление на файловете в акаунта.

Чрез добавяне на следните няколко реда в .htaccess файла, разположен в /public_html, вашият сайт ще зарежда съдържание от желаната поддиректория на /public_html, без това да променя URL адреса:

RewriteEngine Оn
RewriteCond %{HTTP_HOST} ^domainname\.tld$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www\.domainname\.tld$
RewriteCond %{REQUEST_URI} !directoryname/
RewriteRule (.*) /directoryname/$1 [L]

* domainname – името на вашия домейн;
* tld – домейн от първо ниво (Top Level Domain) - .com, .bg, .eu, .net, .org ...;
* directoryname – името на желаната поддиректория на /public_html;

По този начин, достъпвайки вашия домейн с или без www отпред, ще се зарежда съдържанието, което сте разположили в /directoryname.

Трябва да се вземат предвид следните 2 особености относно действието на .htaccess файла:

1. Аpache уеб сървърът обхожда рекурсивно директориите за .htaccess файлове и те влияят на цялото дърво от поддиректории. Поради тази причина са възможни конфликти между Rewrite правилата, описани в .htaccess файлове, разположени в директории и техните поддиректории. Обикновено при еднакви системи или когато няма специфични правила, това не създава проблеми. Въпреки това, трябва да го имате предвид в случаи на некоректно сработване на други директиви. Добра практика е поставянето на .htaccess файлове със съответните правила в папки, намиращи се на едно и също ниво.

2. Някои системи използват глобално зададената на сървъра основна директория за тяхната работа. С посочените по-горе правила се променя само директорията, от която зарежда съдържание вашето уеб приложение. Глобално зададената на сървъра Document Root, остава непроменена: /home/accountname/public_html. Поради тази причина, е необходимо да съобразите начина на работа на софтуера, който използвате във вашия сайт, за да избегнете възможни конфликти. Проверка за настройки в сървъра можете да направите чрез файл с разширение .php (например: p.php), в който въвеждате следното:

<?php
phpinfo();
?>

*accountname - името на вашия акаунт;

Чрез този .php файл се визуализират глобалните настройки на сървъра, както и локално извършените в собствения php.ini файл, който по подразбиране се намира в основната директория на вашия акаунт. В секцията PHP Variables, за _SERVER["DOCUMENT_ROOT"], можете да видите зададената на сървъра основна уеб директория. Тази променлива, може да променя стойността си, например за Add-On домейн, тъй като за него вие имате възможност да посочвате Document Root.

Ще се радваме да споделите като коментар под тази публикация интересни случаи и от вашата практика! Имали ли сте подобни казуси и причини, поради които сте желали смяна на основната директория, от която се зарежда вашия сайт? За какви други особени ситуации, директиви или действия на .htaccess файла искате да научите повече? Питайте! А ние ще ви отговорим и ще предоставим информацията, от която имате нужда?

Не пропускайте да се абонирате за нашия блог и да следите нашата фен страница във Facebook, защото сме ви приготвили още много интересна и полезна информация!

Коментари (16) Връзки за обратно следене (0)
  1. 1

    Добавяне на воден знак към снимки с помощта на .htaccess

    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} -f
    RewriteRule \.(gif|jpeg|jpg|png)$ /път-до-файла/watermark.php [QSA,NC]

    • 1.1

      Благодарим за коментара ви, Николай! :)
      Можем да кажем, че това е възможна реализация за използване на watermark за картинки. Все пак, ако файла watermark.php поставя watermark на всяко извикване, то решението е подходящи за по-малко посещавани сайтове. :) От гледна точка на сървърни ресурси е по-добре да се използва един от следните варианти, при които натоварването на сървъра и използваното CPU ще са по-оптимални:

      1. Да се добави допълнителна проверка дали картинката вече има създаден watermark. Това е необходимо, за да не се слага watermark при всяко извикване. Ако вече картинката има watermark, може да се използват различни варианти за сервирането й. Единият вариант е watermark.php директно да „изпраща“ картинката към браузъра, като зададе правилният content-type в HTTP хедърите. Другият вариант е да се направи пренасочване (302 Found HTTP статус код) към съответния файл, където вече е запазена създадената с watermark картинка в акаунта. При втория вариант, картинката ще се сервира не динамично, а статично от уеб сървъра. Това ще ограничи значително възможността за прекомерно увеличаване на изразходваното CPU и евентуални негативни ефекти върху коректната работа на сайта ви.

      2. Втория вариант, който е още по-оптимален от гледна точка на ресурси, е картинката да се създава с watermark при upload в акаунта и по този начин също ще се реализира статичното сервиране.

    • 1.2

      Интересно е какво следва да съдържа watermark.php

      • Ние препоръчваме дадените насоки за оптимизация на изразходваните сървърни ресурси да се вземат под внимание при реализацията на скрипта. Това е правилната посока за коректна и успешна работа на вашите приложения при всеки вид хостинг решение. Относно съдържанието на watermark.php, то не би трябвало да представлява проблем за реализация от уеб програмист. Също така, има и много безплатни подобни скриптове в Интернет.

  2. 2
    Красен Борисов казва:

    Тази серия от съвети ми харесва все повече с всяка нова тема.

    Ето и нещо полезно:

    Лесно поставяне на сайт във временен режим „поддръжка/ремонт“ чрез преименуване на файл с име maintenance-off на maintenance-on.
    Позволява се публичен дустъп само на определен(и) IP адрес(и) „888.888.888.888″. Форматираната HTML страница (index.html) за този сервизен режим на сайта е в поддиректория „maintenance“.
    Всичко е от гледна точка на public_html директорията.

    RewriteEngine On
    RewriteBase /
    RewriteCond %{HTTP_HOST} ^mydomain.com [NC]
    RewriteRule ^(.*)$ http://www.mydomain.com$1 [L,R=301]
    RewriteCond %{DOCUMENT_ROOT}/maintenance-on -f
    RewriteCond %{REMOTE_ADDR} !^888\.888\.888\.888$
    RewriteRule !^maintenance/.*$ /maintenance/ [R,L]

    • 2.1

      Благодарим ви, Красен, за споделеното мнение и полезната информация! :) Определено имаме чести запитвания как временно на сайта да се визуализира съобщение, че е „Under Construction“. :) Много се радваме, че категорията ви допада! Надяваме се да намирате интересна и полезна информация тук и все по-убедително да печелим доверието на нашите клиенти в професионалните ни мнения и съвети! :)

  3. 3
    монк казва:

    Пренасочване на http://www.sitename.com към sitename.com основно заради СЕО причини:

    RewriteEngine On
    RewriteCond %{HTTP_HOST} !^your-site.com$ [NC]
    RewriteRule ^(.*)$ http://your-site.com/$1 [L,R=301]

    Блокиране на “хотлинкинг“ или още известно като “Стига си ми крал трафика, твойта кожа…“

    RewriteEngine On
    #Replace ?mysite\.com/ with your blog url
    RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ [NC]
    RewriteCond %{HTTP_REFERER} !^$
    #Replace /images/nohotlink.jpg with your „don’t hotlink“ image url
    RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]

    Къстъм страници за грешки:

    ErrorDocument 400 /errors/badrequest.html
    ErrorDocument 401 /errors/authreqd.html
    ErrorDocument 403 /errors/forbid.html
    ErrorDocument 404 /errors/notfound.html
    ErrorDocument 500 /errors/serverr.html

    Премахване на файлови окончания от URL:

    RewriteEngine on
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME}\.html -f
    RewriteRule ^(.*)$ $1.html
    # Replace html with your file extension, eg: php, htm, asp

    Нещо бая важно и полезно: компресиране на файловете, преди да бъдат изпратени към браузъра. Намалява значително трафика, особено ако има много код:

    AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4.0[678] no-gzip
    BrowserMatch bMSIE !no-gzip !gzip-only-text/html

    Хайде със здраве и дано съм ви бил полезен.

    • 3.1

      Здравейте,
      Определено посочените правила за .htaccess са полезни и интересни. Благодарим ви за споделената информация! :)
      Искаме само да направим един коментар относно използването на mod_deflate.
      На сървърите за споделен хостинг не се поддържат модулите mod_deflate и mod_gzip. Може да се използва gzip компресия посредством php, като активирането може да се осъществи по два начина:
      1. Към всеки файл, съдържащ php скрипт преди (X)HTML съдържанието да бъде добавен следния код:

      <?php if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], ‘gzip’)) ob_start(„ob_gzhandler“); else ob_start(); ?>

      2. Създадават се два php файла „gzip_start.php“ и „gzip_stop“, които съдържат следния код:

      - за gzip_start.php:
      <?php
      ob_start(„ob_gzhandler“);
      ?>

      - за gzip_stop.php:
      <?php
      ob_flush();
      ?>

      Двата файла е необходимо да се качат в public_html директорията. За активирането им е необходимо в php.ini файла, който се намира в основната директория на вашия акаунт, посочените по-долу директиви да са както следва:

      auto_prepend_file = /home/your_cpanel_username/public_html/gzip_start.php
      auto_append_file = /home/your_cpanel_username/public_html/gzip_stop.php

      След това, чрез добавянето на следните редове в .htaccess файла може да се активира действието на php.ini файла за всички поддиректории:

      <IfModule mod_env.c>
      SetEnv PHPRC /home/your_cpanel_username/php.ini
      </IfModule>

      Проверка дали е активна gzip компресията, може да се направи посредством phpinfo() файл, както сме описали в статията по-горе.

  4. 4
    Vassilev казва:

    Ще се радвам за повече инфо как ефикасно да блокираме Китайския и Украински спам народ през .htaccess ;)

    • 4.1

      Здравейте,
      Много полезна информация за IP мрежите на различни държави и как да ги блокирате с .htaccess файл, можете да намерите на следния адрес: http://www.countryipblocks.net/
      Като цяло, обаче, ние не препоръчваме това като добра практика. Проследяването на целия списък от IP адреси в .htaccess файла, от една страна, изразходва ресурс, от друга страна, тези мрежи непрекъснато се изменят и не може да разчитате на 100% желан резултат.
      За борба със СПАМ, най-добрата практика е използването на успешно реализиран CAPTCHA код за защита.

  5. 5

    Нещо много полезно за силно натоварени сайтове е добавянето на CDN – Content Delivery Network – това е отделен адрес, който предоставя съдържание, което рядко се променя, като този сървър има специфични настройки… В моя случай имам форум с доста посещения… в CDN съм изнесъл аватарите, снимките и всякакви други картинки, CSS и JS файлове, които на практика се променят доста рядко.

    За целта се създава отделен поддомейн в основния домейн на сайта.
    На този поддомейн в корена се поставя следния .htaccess файл:

    Header unset Pragma
    FileETag None
    Header unset ETag
    Header set Cache-Control „public, no-transform“
    Header unset Last-Modified

    ExpiresActive On
    ExpiresDefault „access plus 1 day“

    Това ще накара браузърите да кешират съдържанието за поне 24 часа. В моя случай това намали трафика на сървъра от 8GB на 6GB, което се е 25% надолу. Освен това cookies на основния домейн са настроени да не са валидни за всички поддомейни. По този начин при зареждането на картинки, CSS и JS файлове не се разменят cookies със сървъра, което също пести доста ресурс, когато има постоянно стартирани сесии…

    Ако имате проблем с това, че ви трябват cookies за всички поддомейни, купувате още един основен домейн, правите го на addon в хостинг панела и качвате на него CDN-а… така вече cookies няма да ходят на CDN-а, дори и да са валидни за всички поддомейни.

    И за да работи всичко лесно и безпроблемно с повечето open source и безплатни системи може да се направят soft-links на сървъра, така че да се свържат различни домейни на сървъра с една и съща директория… Може би това е една нелоша тема за следваща хитрина от съпорта ;)

    • 5.1

      Здравейте, Илия!
      Към коментара ви, можем да допълним, че имаме клиенти, които са реализирали оптимизация на своите приложения, като са изнесли статичното съдържание на своите сайтове на допълнителни виртуални сървъри (VPS). Там използват Lighthpd (http://www.lighttpd.net/) или Nginx (http://nginx.org/), например, които са особено удачни при много видеа и статично съдържание, тъй като тези уеб сървъри се характеризират като по-малко ресурсоемки и с по-голямо бързодействие от Apache. Динамичното съдържание са запазили на акаунтите си на споделен хостинг, където използваме Apache уеб сървър, който е с много повече функционалности, съвместимост с различни приложения и по-широко разпространен. Това можем да кажем, спрямо вашия коментар, че е още по-оптимално реализиран CDN. :) Въпреки, че в основата си CDN-а е разпределено сървърно потребление на отделни физически сървъри (physical nodes), които географски са разположени така, че от различните места, сайта се зарежда от най-близко локирания сървър.

  6. 6
    Мирослав казва:

    ngnix-а е много добро решение за static content. Не само защото е по-лек от apache, има куп предимства сред, които е и решение на C10k проблема.

  7. 7
    Димитър казва:

    Много полезна информация, особено за сайтове които имат проблеми с натоварването, благодаря!

    • 7.1

      Радваме се, че споделената информация е полезна! Ще се постараем да подготвим още интересни теми, с които да ви съдействаме и в бъдеще! :)


Оставете коментар

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Все още няма връзки за обратно следене.