Starší komentáře ke článku: SEO friendly QueryString s pomocí HttpRequest.PathInfo v ASP.NET
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 10.11.2005 10:52:13
Neuvěřitelné. Zrovna včera večer jsem řešil stejný problém :-) Nicméně zde uvedené řešení není dokonalé a chybí mu přesně to na co jsem všera nepřišel: Jak dosáhnout toho, aby v adrese nemusela být "stranka.aspx". Jinak řešeno. Jak přinutit IIS, aby se dotazovalo aplikace (aby se provedl global asax) i v případě zadání neexistující adresy. Tedy například www.server.cz/adresar/podadresar/stranka/. V PHP se tohle dá vyřešit snadno pomocí ReWrite a nasměrovat všechny dotazy mimo obrázků, stylů a nekterých dalších na jeden soubor, který pak požadavek zpracuje, ale jak tohle udělat v .NET?
Datum vložení: 10.11.2005 11:16:33
V Jave su na to Filtre, ktore spracovavaju akukolvek HTTP poziadavku a vedia spravit interny forward. Snad je nieco take aj v .NET, nie?
Datum vložení: 10.11.2005 12:25:22
A proč se snažíte v .NETu řešit záležitosti serveru? Od toho je tady uživatelský skript 404 - v IIS funkční řešení od roku 2000 (u Apače asi o tři roky déle). Dokonce o tom tady na Intervalu byl i článek, relativně nedávno ;-)
Datum vložení: 23.11.2005 7:25:07
Děkuji za zmínku o skriptování 404, cool URIs mi v ASP.NET dosti chyběly a tímto se to velmi úžasně a velmi elegantně řeší.
Datum vložení: 10.11.2005 12:56:08
Dobrý den, to co požadujete, není úplně jednoznačné k vyřešení - pokud tam "vynecháte" někde uprostřed cesty název stránky, tak potom už celá ta cesta nevede na žádnou konkrétní stránku a není tam ani žádné PathInfo. V tomto případě je na serveru, jak se zachová. Výchozí nastavení IIS je takové, že pro požadavky bez uvedení typu souboru není uplatňován ASP.NET filtr, takže takový request vůbec "nespadne" do vaší ASP.NET aplikace. Řešením by bylo nastavit IIS tak, aby i požadavky bez "přípony" směroval na ASP.NET filtr - v aplikaci, která potom takový požadavek obslouží jej můžete dále zpracovat a nejlépe upravit pomocí HTTP modulu. Zpracování přes obsluhu vlastní chyby 404 bych spíše nedoporučil - jednak to není vhodné s ohledem na SEO (dochází k redirektu), a jednak při obsloužení takové chyby vzniká další nadbytečná režie, opravdu je lepší upravit konfiguraci Application Mappings v nastavení IIS a dopsat si HTTP modul, který vám požadovanou URL pomocí RewritePath() upraví. Protože je někdy problém měnit nastavení IIS, pak je řešením použít v adresách vždy nějaký název neexistující stránky avšak s příponou, kterou .net zpracuje - např. Clanek.aspx nebo Stranka.axd.
Datum vložení: 10.11.2005 13:11:15
Pavle, obávám se, že se naprosto zásadně mýlíš. Použití 404 nijak neohrožuje SEO, naopak, čtyřistačtyřka byla tím, co vznik SEO vůbec umožnilo. Navíc skript 404 může zajistit nejen triviální obsluhu URL, lze z něj vytvořit komplexní procesní jádro webbased aplikace. To je známá a v praxi dávno ověřená věc ;-) Při předání požadavku na skript 404 [i]nedochází[/i] k žádnému redirektu (leda že by si ho programátor sám do toho skriptu napsal). Nadbytečná režie také nevzniká - naopak, protože je věc řešena interním mechanismem IIS, je obsluha skriptu 404 efektivnější než jakýkoli možný modul. Praktickou ukázkou může být http://css.interval.cz. Obsluhu neexistujících stránek zajišťuje IIS skrze uživatelský skript 404. V něm je použita kombinace ASP a XML, z něhož se automaticky generuje celý web. Oproti samotnému Intervalu jednodušší asi o padesát skriptů a jednu celou SQL databázi, o efektivitě a výkonnosti ani nemluvím ;-)
Datum vložení: 10.11.2005 13:21:59
Tady došlo k mírnému šumu - já měl na mysli obsluhu chyby 404 přes .net, a tam skutečně dojde k redirektu na chybovou stránku zadanou v sekci customErrors souboru Web.config.
Datum vložení: 10.11.2005 13:24:30
Ale to je záležitost konfigurace, ten redirekt tam být nemusí...
Datum vložení: 14.11.2005 16:43:57
nemohu si pomoct, ale jestlize mam moznost to resit _ciste_ tzn. jak naznacil pavel - filtrovat vse .netem (imho lze omezit pro konkretni domenu konkretni chovani), mod_rewritem, nebo v jave opet filtry vseho, tak nevidim duvod pro to pouzivat 404ku - fakt, ze to rika sefredaktor oborove zamereneho serveru a jeste to propaguje jako _reseni_ mi prijde opravdu zarazejici todle neni reseni, to je berlicka, v jistem smeru flikovani ... systemove se to resi jinak ...
Datum vložení: 17.11.2005 0:21:11
Ano, můžete být zaražen, pokud neznáte historii vývoje těchto technik a technické pozadí jejich realizace. Uživatelské skriptování chyby 404 je nejefektivnějším a nejflexibilnějším nástrojem pro řešení této situace, protože právě ono je tím původním systémovým řešením. Všechna ostatní řešení jsou jen odvozena a nesou sebou ztrátu výkonu, ztrátu flexibility nebo jiná negativa. Takže chcete-li použít "čisté" řešení, pak je to uživatelský skript 404, nikoli filtry a jiné vymyšlenosti. Jak pravil veliký Jára da Cimrman: "Můžeme o tom diskutovat, můžeme o tom vést spory, můžeme s tím i nesouhlasit, ale to je všechno, co se proti tomu dá dělat." ;-)
Datum vložení: 20.11.2005 0:24:30
Diskutovat nebudu, protoze evidentne neni o cem. Vicemene bednu pocitace muzete otevrit klidne tesarskym kladivem, kdyz na to prijde, ale vetsinou je dobry napad pouzit nastroj k tomu urceny i kdyz to mozna trva o chvilku dele ...
Datum vložení: 20.11.2005 1:25:44
Ano, souhlasím s vámi. Framework .Net není určen ke konstrukci Cool URIs - jak můžete i v tomto článku vidět, skutečná Cool URIs neumí, pouze je napodobuje. Zachovejte se tedy podle vlastní rady a připojte se k drtivé většině současných webů, rozumně využívající uživatelské skriptování chyby 404 ;-)
Datum vložení: 20.11.2005 2:24:34
Jeste ctyrikrat a mozna to nalomi slabsi povahy ...
Datum vložení: 20.11.2005 9:49:38
Zřejmě jsem v článku měl více zdůraznit, že pro skutečné plnohodnotné "cool url" se využívají raději HTTP moduly, než v článku ukázané rychlé avšak ne úplně dokonalé řešení. Není pravda, že .net "cool url" neumí, v článku je jasně vidět použití metody RewritePath(), která přesně k tomuto slouží - co této metodě připravíte ke zpracování už je věc druhá. Uvedený článek nemá snahu ukazovat, jak nejlépe vytvářet "cool url" v ASP.NET, cílem bylo ukázat, k čemu může být dobré PathInfo s ohledem na aplikace připravené "po staru". Pro zpracování libovolných "cool url" v ASP.NET pochopitelně slouží různé HTTP moduly, a to mnohem lépe, než obsluha chyby 404 - kdo vyrobí ASP.NET aplikace, tak jistě bude mít zájem, aby vše co v ní bude dít, probíhalo v jejím kontextu, aby veškerá autentizace, autorizace, zpracování Global.asax a třeba také logování, obsluha výjimek, bylo v rámci dané aplikace, nikoli přes obsluhu chyby 404. Nejen pro čistotu řešení, ale také pro to, že obsluha chyby 404 je k dispozici prostě pro neexistující dokumenty - takže cool url, která se třeba v daném CMS shoduje s nějakým existujícím dokumentem na serveru, prostě nezafunguje, server nabídne existující dokument, žádná obsluha 404 se v tomto případě neprovede. Ani v MSDN se o zastaralém používání obsluhy 404 nepíše: http://msdn.microsoft.com/library/en-us/dnaspp/html/urlrewriting.asp
Datum vložení: 20.11.2005 14:39:00
Mohu jen zopakovat, že 404 je původní, univerzální a naprosto čisté řešení, nezávislé na platformě a použitém skriptování, mnohonásobně méně náročné, než od něj odvozené mod_rewrite, mod_alias, či dokonce http moduly. Předposlední odstavec Tvého příspěvku je irelevantní, protože problémy v něm popisované vyplývají z [i]nesprávného[/i] využití skriptování 404. Při použití správné metodiky žádný z popisovaných problémů nenastává. Argumentovat MSDN bych se neodvážil, oba stejně dobře víme, že je zde uvedená dokumentace velké části neúplná a zčásti značně zastaralá, takže například nebere v úvahu řadu vlastností IIS6. A právě skriptování 404 není z hlediska Microsoftu zastaralou metodou, ale naopak metodou nejnověji zavedenou v poslední verzi IIS (zatímco Apache a jiné servery ji právě z důvodu zpracování Cool URIs implementovaly již kolem roku 1997 ;-)
Datum vložení: 13.12.2005 9:45:25
Obavam se, ze to ze pouzivate 404ku uz od nepameti, jeste neni zarukou toho, ze to tak skutecne ma byt a ze je to jedine spravne reseni. 404 je v podstate chybova stranka, je to dokument, na ktery IIS presmeruje vsechny pozadavky na chybejici dokumenty a soubory na webu. Tudiz sem presmerovava i chybejici obrazky, JS apod. Proc by se kvuli kazdemu chybejicimu obrazku mela znovu zpracovavat cela stranka? Vzdyt tech chybejicich veci je mnohdy na webu cela rada a ne vzdy to muze tvurce webu ovlivnit (je to predevsim pripad redakcnich systemu, kde si klient zpravuje web sam). Kdyz to trochu prezenu, tak podle Vasi uvahy by cely IIS a jeho funkce byly zbytecne. Vzdyt staci stranka 404 a ta vsechno obslouzi. Taky nerozumim, jak muze byt stranka 404 zavedena nejnoveji. Nevzpominam si ze bychom si drive museli obsluhy chybejicich stranek na serveru psat sami. Stejne tak neni duvod koukat do MSDN a ptat se tvurce programu (IIS), vzdyt prece chybova stranka 404 je primo urcena k tomu, abychom pres ni honili cely web a veskere pozadavky. ;o)
Datum vložení: 13.12.2005 22:24:01
[i]404 je v podstate chybova stranka, je to dokument, na ktery IIS presmeruje vsechny pozadavky na chybejici dokumenty a soubory na webu. Tudiz sem presmerovava i chybejici obrazky, JS apod. Proc by se kvuli kazdemu chybejicimu obrazku mela znovu zpracovavat cela stranka?[/i] Ano, stránka 404 se postará o každý chybějící dokument, ať už ji uživatelsky skriptujete či nikoli. Pokud nechcete, nic se zpracovávat nemusí, stačí poslat pouze odpovídající hlavičku, přesně jak požaduje patřičný dokument RFC. Záleží jen na schopnostech a znalostech programátora. [i]Taky nerozumim, jak muze byt stranka 404 zavedena nejnoveji. Nevzpominam si ze bychom si drive museli obsluhy chybejicich stranek na serveru psat sami.[/i] Uživatelské skriptování je "novinkou" v oblasti MS serverů - objevilo se u nich až v roce 2000 a plně podporované je až od MS Windows Server 2003 (i když pár věcí funguje doopravdy až v aktuálně vydávané druhé edici). Ostatní servery podobné problémy nemají a uživatelské skriptování 404 je pro ně "stará vesta". Proto programátoři na jiných platformách ani neuvažují nad nahrazováním tohoto vestavěného mechanismu - pro ně je jeho použití samozřejmostí ;-) [i]Stejne tak neni duvod koukat do MSDN...[/i] Dívat se do MSDN je velmi užitečné, nikde jinde jsem třeba nenašel kvalitnější popis XPath. Bohužel, je veřejným tajemstvím, že MSDN jako celek obsahuje značné mezery, ledacos chybí a řada věcí je zastaralá a v současných systémech už nefunguje...
Datum vložení: 28.1.2008 11:51:54
Vsem zucastnenym pouzivajicim 404 nesmysl. Vec se ma takto: Pri 404 chybe jde code-flow pres aspnet_isapi.dll, z tohoto duvodu je to, co se vykonu tyce, naprosto analogicke, jako pri nasazeni HttpModule reseni. HttpModule je zalezitost cista, nabizejici, tak jak tady uz od jednoho z diskutujicich padlo, mnohem vice moznosti, nez 404 (nasobne rewrity, vrstveni logiky). 404 je naopak ta nejvetsi spina, ktera existuje. Sve opodstatneni mela v ASP, nikoliv uz v ASP.NET, ktery nabizi mnohem lepsi reseni v podobe HttpModule. Pro vsechny, kteri se ted nadechuji k odpovedi, ze 404 jsou lepsi - do doby, nez s 404 vyresite odesilani formularu pres POST metodu, radsi mlcte.
Datum vložení: 13.2.2006 16:46:36
Tohle jsem zrovna resil a je to vhodne zejmena pro malo rozsahle weby .. jedna li se o rewriting typu kategorie/podkategorie , pak staci vytvorit adresarovou strukturu shodnou se strukturou kategorie .. do kazde kategorie vytvorit soubor Default.aspx s obsahem pouze <% Page %> a nastavit Default.aspx jako defaultni file ..
Datum vložení: 13.11.2005 11:19:29
Zdravím, teď si nejsem moc jistý, jestli už náhodou nejsem mimo mísu... Ale jak už tu kdosi psal, na intervalu byl o tomto kdysi článek z něhož jsem já osobně téměř nic nepobral, protože .NET a ASP.NET se teprve učím. Jinak na MSDN (kde jinde) je velmi velmi podrobný článek (http://msdn.microsoft.com/library/en-us/dnaspp/html/urlrewriting.asp) o rewritu url (pokud by náhodou odkaz nefungoval, tak stačí zadat vyhledávání s klíčem "mod_rewrite"). A informací v něm lze nalézt víc než dost.
Datum vložení: 13.11.2005 17:01:46
Lze využít ještě další věci a to použít jinou příponu. Třeba htm a pak uživatel vůbec neví, že jde o generované stránky. Stačí když si v IIS namapujete vaši příponu tak, aby jí zpracoval .net framework. Viz záložka Home directory -> Configuration -> Add -> c:\windows\Microsoft.net\framework\{verze}\aspnet_isapi.dll, zvolíle vaší příponu a je to. Pro každou stranku něco.vaše připona se pak zavolá v článku uvedený httpModule. Problém ale je se zadaním pouze adresáře http://www.neco.cz/neco. Buď adresář musí existovat a obsahovat default dokument nebo lze odchytnout přes chybu 404. Script pro odchytnutí stačí, když si zjisti aktuální cestu a doplní třeba default.aspx. Takto to řeším já, s tím že vůbec nepoužívám parametry. Každá stránka ma svůj název, seznam virtuálních stránek i seznam reálných je uložený v XML. A ještě doplnění, pokud máte další aplikace ve virtual directory pod root aplikací s definicí httpModulu, je potřeba tento httpModul, resp. dllko nahrát i do všech podaplikací (podwebů), resp. do adresáře bin. Pro zrušení využívání pak stačí httpModule odstranit pomocí <remove ...>. Bohužel to dllko tam ale musí být :-(
Datum vložení: 21.11.2005 12:03:04
IMHO idealni je pouzit rewrite path, namapovat html na .net (nezapomenout zrusit checkbox "check if file exists") pokud to pouzijete pro aspx a nebudete mapovat html, tak staci jen upravi to zjsitovani pritomnosti jinak prikald na to byl nekde v msdn, vcetne konfigurace pomoci regexp David Bures http://www.sykorka.cz
Datum vložení: 22.11.2005 17:13:00
Jedna vec tu pri polemike k 404 nepadla. Bez riesenia cez 404 handler sa pod IIS<6 || ASP.NET<2 neda zimplementovat wildcard filter, iba handler. Ak si zavesim ASP.NET app ako wildcard handler, nemam v nom moznost odmietnut odhandlovat request a vratit riadenie IIS Tym pridem o dost: - vsetky requesty, aj tie na staticke fajly musi handlovat ASP.NET aplikacia (performance...) - ostatne ISAPI handlery sa nedostanu k slovu, ak mam v approote napr. nejake stare .ASP stranky, nehandluje ich prislusny handler - IIS nerobi directory browsing - IIS nehanduje default documenty - atd. ... Aj z tohoto dovodu je riesenie friendly URL cez 404 skriptovanie stale dost aktualne. V IIS6 pribudla ISAPI handleru moznost odmietnut spracovat request (HSE_REQ_EXEC_URL). Z managed kodu je to dostupne od ASP.NET 2.0. Viac napr. tu: http://blogs.msdn.com/david.wang/archive/2005/10/15/Why_Wildcard_application_mapping_can_disable_Default_Document_resolution.aspx
Datum vložení: 16.12.2005 12:13:00
Vie niekto odporucit profesionalne riesenie vhodne pre web z vysokou navstevnostou? Web je v ASP.NET 2.0
Datum vložení: 16.12.2005 12:30:02
Co to je "vysoká návštěvnost" a "profesionální řešení"? Jestli míříte někam k BBC, použijte proudové generování do speciálního fileserveru, jestli stačí výkon v oblasti nejproduktivnějších českých stránek, pak skriptování 404 (zdarma) nebo odvozené (pro IIS docela mastně zpoplatněné mod_rewrite či mod_alias ;-)
Datum vložení: 16.12.2005 13:44:53
Bude stacit na urovni najproduktivnejsich ceskych stranek ;) Profesionalne riesenie - rychle, mnozstvo funkcii, vychytane muchy... Zatial som dostal odporucania na http://www.isapirewrite.com/
Datum vložení: 16.12.2005 17:19:07
ISAPIrewrite je velmi kvalitní ekvivalent mod_rewrite pro IIS, na Intervalu už se o něm diskutovalo mnohokrát. Fakt je ten, že jde o řešení neúměrně drahé, které přitom neumí nic, co by nezvládl sám IIS - ekonomická stránka věci ovšem na programátorech neleží, že? ;-)
Datum vložení: 20.12.2005 9:20:54
Nie celkom som pochopil "neumí nic, co by nezvládl sám IIS" ... :)
Datum vložení: 27.2.2006 11:15:48
Nestacilo by toto: http://www.aspnet.cz/Articles/44-tovarna-na-absolutni-url-rewriting-pomoci-ihttphanderfactory.aspx
Datum vložení: 14.1.2006 13:10:13
Dobrý den, mám s tímto problém. Při pokusu o spuštění ukázkové stránky, která je zde ke stažení mi server vyhodí chybu: [i]Could not load file or assembly 'PathInfo2QueryString' or one of its dependencies. Systém nemůže nalézt uvedený soubor.[/i] Chybu způsobuje tento řádek: [i]<add name="PathInfo2QueryString" type="Interval.CZ.Common.WebHttpModules,PathInfo2QueryString" />[/i] Nevíte jak toto vyřešit?
Datum vložení: 16.1.2006 9:21:44
Dobrý den, z chybového hlášení je zřejmé, že nemáte na serveru zkompilovanou assembly s HTTP modulem. Assembly je potřeba vytvořit zkompilováním zdrojového kódu knihovny, ta je v ukázce přiložena.