Serveri viga rakenduse ressursis ei õnnestu leida, URL on õige, kuid href ei tööta .netis

Kolime tuhandeid alamkatalooge alamdomeeni. Täpselt sama nälkjas, kuid see on nüüd alamdomeen. Kõik need alamkataloogid põhjustavad 404.

Kuidas ma saan htaccessi kasutades viia 404 rämpsposti aadressil domain.com/slug/ ja suunata aadressile slug.domain.com?

Ma hindan kellegi aega!

  • Kas pärast /slug/ URL-i teel?
  • Ei, mitte kunagi. Selle sidussüsteem on nii, et domeenist.com/affiliates-slug/ saaks täpselt sidusettevõtte-slug.domain.com, erinevus on ainult alamdomeenile alam.

Kasutades mod_alias's RedirectMatch

RedirectMatch permanent '^/?([a-z0-9\-]+)/?$' 'https://$1.example.com/' 

Kasutades mod_rewrite:

RewriteRule '^/?([a-z0-9\-]+)/?$' 'https://$1.example.com/' [R=301,L] 

See suunab ümber ainult kataloogid, mis koosnevad alamdomeenide jaoks ohututest märkidest (numbrid, tähed ja kriipsud - [a-z0-9\-]). See ei kontrolli, kas see algab või lõpeb kriipsuga (pole lubatud alamdomeenina), nii et seda saaks natuke paremaks muuta. Veendumaks, et see ei algaks ega lõppeks kriipsuga, võite selle asemel kasutada [a-z0-9]+(-+[a-z0-9]+)* sulgude sees.

Kaldkriipsud on mõlemad valikulised ( ? pärast iga kaldkriipsu). See tähendab, et see suunab mõlemad ümber /slug ja /slug/. Esimene kaldkriips on valikuline vaid seetõttu, et see muudab reegli mod_rewrite kaasaskantavaks. See töötab kas .htaccessis või teie Apache .conf-failis.

The ^ ja $ reeglite kohta on vastavalt "algab" ja "lõpeb". See tähendab, et reeglid ei ühti URL-ide osaliste teedega.

Sulgusid kasutatakse rühmitamiseks. The $1 on tekst, mis tõmmatakse sulgude seest (esimesest komplektist).

Need eeldavad, et alamdomeene käsitletakse teises kataloogis ja erandeid pole. Kui teil on erandeid, võite need reeglite ümberkirjutamise tingimustena lisada. Näiteks võiksite teha erandeid kõigi olemasolevate failide kohta. Erandiks võib olla ka see, et nad töötavad ainult teie peamise hosti nime juures ja ei püüa nuhke alamdomeenidel ümber suunata. Nagu nii:

RewriteCond '%{HTTP_HOST}' 'www.example.com' [NC] RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-l RewriteRule '^/?([a-z0-9\-]+)/?$' 'https://$1.example.com/' [R=301,L] 
  • Aitäh, aga ma ei saa aru, kuidas see kontrollib, kas alamkataloog on 404 või mitte. Meil on eemaldatavad alamjuhised, mis genereerivad 404 ja kui ma genereerin 404, siis tahan suunata alamdomeeni. Vastasel juhul on meil ka alamkatalooge, mis jäävad tavalisteks lehtedeks, nii et mulle jääb mulje, et see htaccess-sisu peaks enne ümbersuunamist kontrollima, kas see on 404. Aitäh!
  • Need RewriteCond takistaks seda tegelikult olemasoleva faili ümbersuunamisest.
  • Hämmastav, ma ei saanud kunagi aru, et see kontrollib, kas rada on olemas või mitte. Aitäh!

Juure ülaosas mod_rewrite abil saate teha midagi järgmist .htaccess fail peamises domeenis:

RewriteEngine On RewriteCond %{DOCUMENT_ROOT}/$1 !-d RewriteRule ^([^./]+)/$ https://$1.example.com/ [R=302,L] 

The RewriteRule muster ^([^./]+)/$ vastab ainult esimesele (ja ainsale) teesegmendile, välja arvatud failid (kuna muster välistab punktid). The kohustuslik lõpukaldkriips on jäädvustamisalamast välja jäetud. Soovitav oleks seda muuta, et see vastaks ainult kehtivale alamdomeeni mustrile, nagu @ Stepheni vastuses.

Eelnev tingimus (RewriteCond direktiiv) tagab, et päring ei kaardistata olemasolevat kataloogi. (Ma eeldan, et teil on kehtiv kataloog, mis peab endiselt toimima.)

$1 on taustreferents pildistatud tee segmendile URL-teelt, välja arvatud esimene ja lõppkriips, st. slug teie näites.

Pange tähele, et see on ajutine (302) ümbersuunamine. Alaliseks (301) muutke see ainult siis, kui see on eesmärk - kui olete kinnitanud, et see töötab korras. Selle eesmärk on vältida vahemäluprobleeme.

Näited:

Ülaltoodud direktiivide kohaldamine ...

A. Taotlus example.com/slug/.

  1. slug/ sobib RewriteRule muster ^([^./]+)/$
  2. /slug ei eksisteeri failisüsteemi kataloogina.
  3. Suunatud aadressile https://slug.example.com/. EDU

B. Taotlus example.com/directory/.

  1. directory/ sobib RewriteRule muster ^([^./]+)/$
  2. /directory eksisteerib failisüsteemi kataloogina. FAIL

C. Taotlus example.com/directory/something.

  1. directory/something ei ühti RewriteRule muster ^([^./]+)/$. FAIL

D. Taotlus example.com/file.html.

  1. file.html ei ühti RewriteRule muster ^([^./]+)/$. FAIL

E. Taotlus example.com/slug (ei kaldkriipsu).

  1. slug ei ühti RewriteRule muster ^([^./]+)/$. FAIL
  • Aitäh, aga ma ei saa aru, kuidas see kontrollib, kas alamkataloog on 404 või mitte. Meil on eemaldatavad alamjuhised, mis genereerivad 404 ja kui ma genereerin 404, siis tahan suunata alamdomeeni. Vastasel juhul on meil ka alamkatalooge, mis jäävad tavalisteks lehtedeks, nii et mulle tundub, et see htaccess-sisu peaks enne ümbersuunamist kontrollima, kas see on 404. Aitäh!
  • Ma loen teie vastust uuesti läbi ja näib, et te tegite seda tegelikult, mul on lihtsalt raske seda töödelda. Tegelikult on meil .com / asjad / mis jäävad puutumatuks. Siis on meil lugematu arv .com / stuffs /, mida enam ei eksisteeri, kuid need asendatakse metsmälu abil alamdomeenidega.
  • 1 Ülaltoodust järeldub, et päring ei kaardista füüsilist kataloogi (või faili - eeldades, et kõigil failidel on punktiga piiritletud "faililaiend"). Niisiis, kui see ei kaardista kataloogi ega faili, siis on see 404 ... kui ... te ei suunata URL-e CMS-i kaudu ja 404-d määrab CMS? Kui see nii on, siis ei saa te seda teha .htaccess kuna sel ajal oleks võimatu kindlaks teha, mis on 404 või mitte .htaccess töödeldakse.
  • Lisasin mõned näited selle kohta, mis juhtub nende direktiivide rakendamisel erinevatele URL-i päringutele. Pange tähele, et olen eeldanud, et kaldkriips on kohustuslik, kuna olete selle oma küsimuses lisanud URL-i näidisele.
  • Kuidas sa sellega hakkama said?

none: Charles Robertson | none

none