[ASP.NET] Error handling op web.config, IIS,applicatieniveau

[Goldme]

Ik ben bezig met het afhandelen van fouten voor een ASP.NET webapplicatie. Nu blijkt dat foutafhandeling op verschillende niveaus kan plaatsvinden:

-code niveau(try-catch)
-page niveau(page_error)
-application niveau(application_error in global.asax)
-web.config(customerrors)
-IIS


Die volgorde is dan ook de volgorde waarin de event omhoog bubbelt. Nu is de vraag: waar vang ik welke errors op?

op code niveau: de normale exceptionhandling

page niveau: gebruik ik niet

application niveau: gebruik ik alleen om exception te loggen

web.config en IIS: geen idee!!!!!!

Ik wil namelijk reageren op de verschillende statuscodes zoals 401, 404, 403_4(ssl required) en 500(internal server error, meestal unhandles exception in code)

Echter, als ik die errors instel via web.config(customerrors gekoppeld aan statuscodes) dan worden die waardes alleen aangesproken als de opgevraagde pagina een .NET pagina is(zoals .aspx). Errors als 403_4 krijg ik met geen mogelijkheid bij de web.config aangezien deze eerder worden afgevangen door IIS voordat die de webapplicatie bereikt. Ook 404(file not found) werkt gebrekkig: als ik een .aspx opvraag dan wordt de waarde uit de web.config gebruikt bij "file not found", bij normale .htm files wordt door IIS een normale 404 getoond.

Ik kan die error-pages ook op IIS-website niveau instellen maar dat lijkt me niet echt netjes. Ik wil echter wel 403_4 errors opvangen dus lijk ik geen andere mogelijkheid te hebben. Klopt die?

[whoami]

Ik dacht dat je de 401 / 404 error's best kunt opvangen op web.config niveau. Je kan daar met status oid gaan werken, en definieren welke pagina er moet getoond worden bij een 404.
Hoe het precies weer in z'n werk gaat, weet ik niet meer. 't Is al een tijd geleden dat ik nog wat met asp.net gedaan heb.

[Verwijderd]

Het kan idd. En wel zo:

code:

<configuration>
  <system.web>
       <customErrors defaultRedirect="ErrorPage.aspx" mode="On">   
          <error statusCode="500" redirect="servererror.aspx" />
          <error statusCode="404" redirect="filenotfound.aspx" />
         <error statusCode="403" redirect="AccessDenied.aspx" /> 
      </customErrors>
   </system.web>
</configuration>

[Shir]

Maar dan worden .html bestanden die niet worden gevonden nog steeds door IIS opgevangen.

[gorgi_19]

Shir schreef op 23 juni 2004 @ 09:28:
Maar dan worden .html bestanden die niet worden gevonden nog steeds door IIS opgevangen.

Je moet ook alle bestanden door de asp.net parser laten gaan, ook .html bestanden.

[whoami]

gorgi_19 schreef op 23 juni 2004 @ 09:30:
[...]

Je moet ook alle bestanden door de asp.net parser laten gaan, ook .html bestanden.

En dat leg je op in IIS ?

[gorgi_19]

whoami schreef op 23 juni 2004 @ 09:45:
[...]


En dat leg je op in IIS ?

Ja, zie deze link via Google; dan het gedeelte vanaf het kopje "Finally"

[tijn]

gorgi_19 schreef op 23 juni 2004 @ 09:30:
[...]

Je moet ook alle bestanden door de asp.net parser laten gaan, ook .html bestanden.

Dit is wel vrij dodelijk voor de performance. Ook alle plaatjes etc. worden nu door de ASP.NET engine afgehandeld. Op een pagina met vrij veel plaatjes kun je het verschil erg goed merken, zelfs als je in je eentje op je eigen server zit te surfen.

[gorgi_19]

tijn schreef op 23 juni 2004 @ 10:06:
[...]

Dit is wel vrij dodelijk voor de performance. Ook alle plaatjes etc. worden nu door de ASP.NET engine afgehandeld. Op een pagina met vrij veel plaatjes kun je het verschil erg goed merken, zelfs als je in je eentje op je eigen server zit te surfen.

Je kan dan er voor kiezen om de boel (plaatjes) in een aparte application te doen, waardoor deze er geen last van heeft.

Een andere optie is om een eigen pagehandler er voor te gaan maken en deze te definieren in je web.config. Geen idee trouwens of je ook eea kan laten regelen mbv caching icm een eigen pagehandler, waardoor het performanceverlies (praktisch) nihil zou moeten zijn.

[ Voor 12% gewijzigd door gorgi_19 op 23-06-2004 10:11 ]

[Verwijderd]

Zo zorg je d'r voor dat alleen .htm door asp .net heen gaat:

- Control panel
- Administrative tools
- Expand Internet Information Service
- Click on web
- Click on Action menu, select properties
- Click on directory tab
- Click configuration (button???) to display application configuration dialog box
- Click add to display add/edit application extention mapping dialog box
- Click browse and select aspnet_isapi.dll
- Type .htm in the File Extension box
- Click OK

[tijn]

gorgi_19 schreef op 23 juni 2004 @ 10:10:
[...]
Een andere optie is om een eigen pagehandler er voor te gaan maken en deze te definieren in je web.config. Geen idee trouwens of je ook eea kan laten regelen mbv caching icm een eigen pagehandler, waardoor het performanceverlies (praktisch) nihil zou moeten zijn.

Hehe ja, dat kan idd. In .Text zit ook zoiets. Toch vind ik het wel tricky om hiermee aan de gang te gaan. Als je je spul uiteindelijk laat hosten op shared-hosting weet ik niet of ze zomaar ff alle extensies naar ASP.NET gaan mappen.