Какво ми липсва? Ако отида в mysite.com:9999 Получавам сайта си, но не mysite.com Очевидно потребителите не трябва да въвеждат в порта, така че какво трябва да направя? Всъщност не се опитвам да скрия порта толкова много, колкото да не изисквам от потребителя да го въвежда в URL адреса. Това настройка за конфигурация на Apache ли е някъде? Трябва ли да разглеждам httpd.config, config config или другаде? Това е виртуален хост на сървър на Apache. Всички предложения се оценяват.

редактиране- работещите виртуални хостови блокове в virtualhosts.conf изглеждат така:

Близо до началото записите на виртуалния хост са наречени по следния начин:

NameVirtualHost *:700 NameVirtualHost *:710 ... NameVirtualHost *:760 

Под работния блок за http версията изглежда така:

 ServerName webdev.url.com ServerAdmin [email protected] # Comment out when OC4J instance is down for maintenance:  Oc4jMount  # Uncomment when OC4J instance is down for maintenance: # DocumentRoot '/org/dev' # - Restrict 'Cross-Site-Tracking' or XST RewriteEngine on RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F]  DirectoryIndex index.jsp  ErrorLog '|/opt/app/oracle/product/AS10.1.2/Apache/Apache/bin/rotatelogs/logs/dev_error_log 440' CustomLog '|/opt/app/oracle/product/AS10.1.2/Apache/Apache/bin/rotatelogs/logs/dev_access_log 440' common  Order deny,allow Deny from all Allow from ####internal ip addresses####   

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

## - for Mobile  ServerName mdev.url.com ServerAdmin [email protected] # Comment out when OC4J instance is down for maintenance:  Oc4jMount / msitedev  # - Restrict 'Cross-Site-Tracking' or XST RewriteEngine on RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F]  DirectoryIndex m.jsp  ErrorLog '|/opt/app/oracle/product/AS10.1.2/Apache/Apache/bin/rotatelogs/logs/mdev_error_log 440' CustomLog '|/opt/app/oracle/product/AS10.1.2/Apache/Apache/bin/rotatelogs/logs/mdev_access_log 440' common #  # Order deny,allow # Deny from all # Allow from #### #   

Отново се опитвам да разбера дали нещо тук потиска необходимостта от въвеждане на порт # (напр. 710) в URL адреса. При проверка изглежда, че никъде няма файлове с htaccess.

  • Слушате ли нещо на порт 80? Може би нещо различно от ? Нещо като ? Като страна (и нямам предвид да ви отблъсна друга SE), става ли това по-подходящо за ServerFault?
  • Ако смятате, че това е по-подходящо ... има ли начин да мигрирате въпроса, вместо да го пресъздадете? В един момент имаше Listen #.#.#.#:80 и NameVirtualHost#.#.#.#:80 блок, но сега се коментира.
  • Виждам, че в default-web-site.xml за този контейнер има нещо като:
  • Потвърдено, че със сигурност няма .htaccess файл.
  • Виждате ли отговора от LazyBadger по-долу? Възможно ли е да разгледате файла на зоната или да копаете някой от работещите домейни, за да видите дали има SRV изявление?

Ето ръководството за DNS SRV записи (RFC 2782), което може да се използва за промяна на порта по подразбиране, за да съответства на това, което всъщност използвате:

_http._tcp.example.com. IN SRV 0 5 80 www.example.com. 

където до последното поле е порт, който може да има всякаква реална стойност. DNS SRV записите могат да дефинират по подразбиране http порта за домейн или само за (някои) хостове вътре в домейна

  • @LazyBadger Така че, за да проверим дали ако това всъщност се прави със съществуващите им хостове, ще трябва да видим Zone File?
  • @Nathan да. Или изкопайте съответните записи
  • Това наистина е много спретнато! Благодаря Мързелив язовец! Бях забелязал SRV записи и преди, но всъщност не бях обмислял как бих могъл да ги използвам. Знаете ли, направих STFW, преди да се опитам да отговоря, но не трябва да съм търсил с правилните термини.
  • 1 Този отговор за съжаление е грешен, доколкото мога да разбера. SRV записите не могат да се използват с HTTP протокола или дори технически да не са нарушение на протокола, той има нулева поддръжка на браузъра. stackoverflow.com/a/9063595/2234742

Когато въвеждате URL адреса в уеб браузър, http://www.foo.com, ще стане винаги опит за свързване на порт 80.

Не е толкова много, че се намира пристанището скрити, но по-скоро това е битие предполага се, тъй като порт 80 е по подразбиране за HTTP заявки.

По същия ред, ако прегледате https://www.foo.com, той винаги ще се опитва да се свърже на порт 443, освен ако не посочите друг порт (https://www.foo.com:8080). Порт 443 е портът по подразбиране за SSL / TLS заявки.

Освен ако нямате убедителна причина (защото, например, ако използвате 2 уеб услуги [напр. Apache и IIS] едновременно на машината), може би е най-добре просто да смените новия си виртуален хост на порт 80. Снапване малко, В SO видях, че сте задали подобен въпрос. Ако се опитвате да пренасочите мобилни клиенти към различен сайт (или вашето приложение например), можете да използвате mod_rewrite въз основа на потребителския агент.

Например:

 DocumentRoot /www/mainwebsite ServerName www.foo.com RewriteEngine On RewriteCond %{HTTP_USER_AGENT} 'android|blackberry|googlebot-mobile|iemobile|ipad|iphone|ipod|opera mobile|palmos|webos' [NC] RewriteRule ^$ http://m.foo.com/ [L,R=302]   DocumentRoot /www/mobileapp ServerName m.foo.com # You might check for the USER_AGENT here and redirect to the main site if not found  

Късно е и горното може да е малко изключено - ако това е полезно за вас, може би някой може да го редактира, за да бъде по-правилно.

  • Що се отнася до порта, вече има няколко други виртуални хоста в същото поле, всички използващи портове, различни от 80 или 443, и не е нужно да посочваме портове в URL адреса. Вече сме обработили пренасочването, но благодаря за предложението. Като страна настрана забелязах, че ако отидете за .*mobile*android|android*mobile.* избягва таблетките. Проектираме така, че мобилният телефон да изглежда прилично на таблети, но решихме, че няма причина автоматично да ги пренасочваме или ipad, когато основният сайт е достатъчен, и те винаги могат да го избират чрез връзки напред-назад.
  • @dallas Можете ли да проверите за .htaccess файл в корена на някои от виртуалните хостове, които работят? Ще обмисля това малко повече след обяд.
  • Мога да проверя сутринта. Когато за първи път разглеждахме как да направим пренасочването, беше предложено да го направим с файла .htaccess. Огледах се и не видях съществуващ. Всъщност не знаех къде трябваше да гледам по това време. Когато казвате root, имате предвид мястото, където са били конфигурационните файлове за това VH sit или DocumentRoot? Не видях такъв в DocumentRoot за основния регион на разработчика на сайт, който работи.
  • 1 За да пренасоча foo.com към foo.com:9999, не мога да измисля начин да пренасоча заявка от порт 80 към друг порт, без да има VirtualHost на порт 80 поне да „слуша“ заявките. Ако .htaccess файл по някакъв начин се справя с пренасочването, пак ще трябва да има нещо на foo.com, което слуша на порт 80. Файлът .htaccess ще бъде в DocumentRoot на VirtualHost, слушащ на порт 80. Мислите ли, че можете да поставите а segment in your above question (edit the question) from one of the hosts that is working? Thinking... mod_proxy might be involved, too.

The HTTP protocol uses port 80 by default. If you configure your web server to use a nonstandard port, then the port needs to be specified in the URL. There's no way to hide that.

In Apache, you can set the listening port in <?php httpd.conf, напр .:

Listen 127.0.0.1:80 

Това обаче може да бъде заменено в конфигурацията на vhost, напр .:

 
  • Вече го прави за други виртуални хостове в същото поле, но не знам къде да търся или как се прави.
  • @Dallas: вашите vhost конфигурации могат да бъдат посочени в httpd.conf или в отделен conf файл (обикновено httpd-vhosts.conf в директорията за допълнителни конфигурации). Просто извършете търсене във вашата конфигурационна директория за '9999' и бихте могли да намерите къде се посочва този номер на порт. Тогава просто го заменете с 80 и трябва да сте добре.
  • Посочваме порт както в Listen, така и във VirtualHost. Не разбрах, че го заменя. Просто предположих, че трябва да бъде посочено и в двете.
  • @Dallas: обикновено се посочва и в двете; само ако това, което посочите във вашата директива VirtualHost е различно от директивата Listen, тогава настройките на директивата VirtualHost ще бъдат следвани за този vhost.
  • virtualhosts.conf е мястото, където изглежда всичко, но не виждам нищо, което изглежда да крие използваните портове.

Едва сега осъзнавам, че никога не съм публикувал конкретния отговор на проблема си.

В крайна сметка трябваше да добавим подробности към webcache.xml, за да позволим на URL адреса да работи без порт, посочен в URL адреса.

е работил за вас: Charles Robertson | Искате ли да се свържете с нас?