👨‍👦‍👦 👎🏼 🏂🏿 ASP.NET MVC पर मूल 404 त्रुटि पृष्ठ 🎫 🦋 👋🏽

ASP.NET MVC पर एक परियोजना विकसित करते समय, मेरा अपना 404 त्रुटि पृष्ठ बनाना आवश्यक हो गया। मुझे उम्मीद थी कि मैं इस कार्य को कुछ ही मिनटों में सामना कर सकता हूं। 6 घंटे के काम के बाद, मैंने जटिलता के अलग-अलग डिग्री के समाधान के लिए दो विकल्पों की पहचान की। नीचे विवरण।

ASP.NET MVC 3 में, जिसके साथ मैं काम करता हूं, वैश्विक फ़िल्टर प्रकट हुए हैं। एक नए प्रोजेक्ट के टेम्प्लेट में, इसका उपयोग पहले से ही अपने स्वयं के त्रुटि पृष्ठ ( हैंडललीट्रेट एट्रिब्यूट के माध्यम से) को प्रदर्शित करने के लिए बनाया गया है। एक अद्भुत विधि, केवल यह कोड 404 (पाया नहीं गया) के साथ त्रुटियों को संभाल नहीं सकता है। इसलिए, मुझे इस त्रुटि से निपटने के लिए एक और सुंदर विकल्प की तलाश करनी थी।

Web.config के माध्यम से 404 त्रुटि से निपटने

ASP.NET प्लेटफॉर्म Web.config फ़ाइल के सरल कॉन्फ़िगरेशन के माध्यम से मनमाने ढंग से त्रुटियों को संभालने की क्षमता प्रदान करता है। ऐसा करने के लिए, निम्न कोड को system.web अनुभाग में जोड़ें:

<customErrors mode="On" > <error statusCode="404" redirect="/Errors/Error404/" /> </customErrors>

यदि 404 त्रुटि होती है, तो उपयोगकर्ता को yourite.ru/Errors/Error404/?aspxerrorpath=/Not/Found/Url पृष्ठ पर भेजा जाएगा। इस तथ्य के अलावा कि यह बहुत सुंदर और सुविधाजनक नहीं है (आप यूआरएल को संपादित नहीं कर सकते हैं), यह एसईओ के लिए भी बुरा है - habr.ru पर एक लेख।
रिडायरेमोड = "ResponseRewrite" को customErrors में जोड़कर विधि को थोड़ा सुधारा जा सकता है:

 <customErrors mode="On" redirectMode="ResponseRewrite" > <error statusCode="404" redirect="/Errors/Error404/" /> </customErrors>

इस स्थिति में, त्रुटि प्रसंस्करण पृष्ठ पर पुनर्निर्देशित नहीं होना चाहिए, लेकिन अनुरोधित त्रुटि पथ को निर्दिष्ट पृष्ठ की सामग्री से बदल दिया जाएगा। हालाँकि, कुछ कठिनाइयाँ हैं। ASP.NET MVC पर दिए गए फॉर्म में यह विधि काम नहीं करती है। विषय में एक काफी विस्तृत चर्चा (अंग्रेजी में) पढ़ी जा सकती है। संक्षेप में, यह विधि Server.Transfer विधि पर आधारित है, जिसका उपयोग क्लासिक ASP.NET में किया जाता है और, तदनुसार, केवल स्थिर फ़ाइलों के साथ काम करता है। गतिशील पृष्ठों के साथ, उदाहरण के लिए, यह काम करने से इंकार कर देता है (क्योंकि यह डिस्क पर फ़ाइल / त्रुटियाँ / त्रुटि404 / 'नहीं देखता है)। यही है, यदि आप उदाहरण के लिए '/ त्रुटियाँ / Error404 /' को प्रतिस्थापित करते हैं, '/' Errors/Error404.htm ', तो वर्णित विधि काम करेगी। हालांकि, इस मामले में, अतिरिक्त त्रुटि से निपटने की क्रिया करना संभव नहीं होगा, उदाहरण के लिए, लॉगिंग।
निर्दिष्ट विषय में, प्रत्येक पृष्ठ पर निम्नलिखित कोड जोड़ने का प्रस्ताव था:

 Response.TrySkipIisCustomErrors = true;

यह विधि केवल IIS 7 और उच्चतर के साथ काम करती है, इसलिए इस विधि को सत्यापित नहीं किया जा सकता है - हम IIS 6 का उपयोग करते हैं। हमें खोज जारी रखना था।

एक टैम्बोरिन और Application_Error के साथ नृत्य

यदि ऊपर वर्णित विधि किसी कारण से लागू नहीं की जा सकती है, तो आपको कोड की अधिक पंक्तियां लिखनी होंगी। लेख में एक आंशिक समाधान दिया गया है।
सबसे पूर्ण समाधान "एक टैम्बोरिन के साथ" मुझे विषय में मिला। चर्चा अंग्रेजी में है, इसलिए मैं निर्णय के पाठ का रूसी में अनुवाद करूंगा।
नीचे 404 NotFound त्रुटि प्रदर्शन समस्या को हल करने के लिए मेरी आवश्यकताएं हैं:

मैं उन रास्तों को संभालना चाहता हूं जिनके लिए कोई एक्शन परिभाषित नहीं है।
मैं उन रास्तों को संभालना चाहता हूं जिनके लिए एक नियंत्रक परिभाषित नहीं है।
मैं उन रास्तों को संभालना चाहता हूं जो मेरा आवेदन पार्स करने में विफल रहे। मैं नहीं चाहता कि इन त्रुटियों को Global.asax या IIS में संभाला जाए, क्योंकि तब मैं अपने एप्लिकेशन पर वापस रीडायरेक्ट नहीं कर पाऊंगा।
मैं अपनी खुद की प्रक्रिया करना चाहता हूं (उदाहरण के लिए, जब आवश्यक उत्पाद आईडी द्वारा नहीं मिला है) एक ही शैली में 404 त्रुटियां।
मैं चाहता हूं कि सभी 404 त्रुटियां एक एमवीसी व्यू लौटाएं, न कि एक स्थिर पेज, ताकि बाद में मुझे अधिक त्रुटि डेटा मिल सके। और उन्हें 404 स्टेटस कोड वापस करना चाहिए ।

मुझे लगता है कि Global.asax में Application_Error का उपयोग उच्च-स्तरीय उद्देश्यों के लिए किया जाना चाहिए, उदाहरण के लिए, बिना किसी अपवाद या लॉगिंग को हैंडल करने के लिए, और 404 त्रुटि के साथ काम नहीं करना चाहिए। इसलिए, मैं 40 फ़ाइल के साथ जुड़े सभी कोड को ग्लोबल फ़ाइल से बाहर रखने का प्रयास करता हूं। asax।

चरण 1: 404 त्रुटियों को संभालने के लिए एक आम जगह बनाएं

इससे समर्थन निर्णय लेने में आसानी होगी। हम भविष्य में 404 पेज को बेहतर बनाने के लिए ErrorController का उपयोग करते हैं। आपको यह भी सुनिश्चित करने की आवश्यकता है कि नियंत्रक 404 कोड लौटाता है!

 public class ErrorController : MyController {  #region Http404  public ActionResult Http404(string url)  {    Response.StatusCode = (int)HttpStatusCode.NotFound;    var model = new NotFoundViewModel();    //    ('NotFound' route),           model.RequestedUrl = Request.Url.OriginalString.Contains(url) & Request.Url.OriginalString != url ?      Request.Url.OriginalString : url;    //     Referrer  Request    model.ReferrerUrl = Request.UrlReferrer != null &&      Request.UrlReferrer.OriginalString != model.RequestedUrl ?      Request.UrlReferrer.OriginalString : null;    // TODO:   ILogger    return View("NotFound", model);  }  public class NotFoundViewModel  {    public string RequestedUrl { get; set; }    public string ReferrerUrl { get; set; }  }  #endregion }

चरण 2: हम नियंत्रकों के लिए अपने स्वयं के आधार वर्ग का उपयोग करते हैं ताकि 404 त्रुटि के लिए विधि को कॉल करना आसान हो सके और हैंडललीडॉग्रेशन को संभाल सकें

ASP.NET MVC में त्रुटि 404 को कई स्थानों पर नियंत्रित करने की आवश्यकता है। पहला हैंडलडेनगेंशन है।
InvokeHttp404 विधि ErrorController और हमारे नए बनाए गए Http404 कार्रवाई के लिए पुनर्निर्देशित करने के लिए एक जगह है। DRY कार्यप्रणाली का उपयोग करें!

 public abstract class MyController : Controller { #region Http404 handling protected override void HandleUnknownAction(string actionName) { //   - ErrorController,       if (this.GetType() != typeof(ErrorController)) this.InvokeHttp404(HttpContext); } public ActionResult InvokeHttp404(HttpContextBase httpContext) { IController errorController = ObjectFactory.GetInstance<ErrorController>(); var errorRoute = new RouteData(); errorRoute.Values.Add("controller", "Error"); errorRoute.Values.Add("action", "Http404"); errorRoute.Values.Add("url", httpContext.Request.Url.OriginalString); errorController.Execute(new RequestContext( httpContext, errorRoute)); return new EmptyResult(); } #endregion }

चरण 3: नियंत्रक कारखाने में निर्भरता इंजेक्शन का उपयोग करें और 404 HttpException को संभालें

उदाहरण के लिए, इस तरह (आपको संरचना का उपयोग करने की आवश्यकता नहीं है):
MVC1.0 के लिए उदाहरण:

 public class StructureMapControllerFactory : DefaultControllerFactory { protected override IController GetControllerInstance(Type controllerType) { try { if (controllerType == null) return base.GetControllerInstance(controllerType); } catch (HttpException ex) { if (ex.GetHttpCode() == (int)HttpStatusCode.NotFound) { IController errorController = ObjectFactory.GetInstance<ErrorController>(); ((ErrorController)errorController).InvokeHttp404(RequestContext.HttpContext); return errorController; } else throw ex; } return ObjectFactory.GetInstance(controllerType) as Controller; } }

MVC2.0 के लिए उदाहरण:

  protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType) { try { if (controllerType == null) return base.GetControllerInstance(requestContext, controllerType); } catch (HttpException ex) { if (ex.GetHttpCode() == 404) { IController errorController = ObjectFactory.GetInstance<ErrorController>(); ((ErrorController)errorController).InvokeHttp404(requestContext.HttpContext); return errorController; } else throw ex; } return ObjectFactory.GetInstance(controllerType) as Controller; }

मुझे लगता है कि उनकी घटना के स्थान पर त्रुटियों को पकड़ना बेहतर है। इसलिए, मैं Application_Error में त्रुटि से निपटने के लिए ऊपर वर्णित विधि पसंद करता हूं।
404 त्रुटियों को पकड़ने के लिए यह दूसरा स्थान है।

चरण 4: उन मार्गों के लिए GlobalFasax में NotFound मार्ग जोड़ें, जो हमारा एप्लिकेशन निर्धारित नहीं कर सका

इस मार्ग को Http404 कार्रवाई को ट्रिगर करना चाहिए। कृपया ध्यान दें कि url पैरामीटर एक सापेक्ष पता होगा, क्योंकि रूटिंग इंजन डोमेन नाम के साथ भाग को काट देता है। यही कारण है कि हमने पहले चरण में इन सभी सशर्त बयानों को जोड़ा।

  routes.MapRoute("NotFound", "{*url}", new { controller = "Error", action = "Http404" });

यह 404 त्रुटियों को पकड़ने के लिए एमवीसी आवेदन में तीसरा और अंतिम स्थान है जो आप स्वयं का कारण नहीं बनते हैं। यदि यहां आने वाले मार्ग को किसी भी नियंत्रक और कार्रवाई में मैप करना संभव नहीं था, तो MVC इस त्रुटि के प्रसंस्करण को ASP.NET प्लेटफ़ॉर्म (Global.asax फ़ाइल में) से आगे पारित करेगा। और हम नहीं चाहते कि ऐसा हो।

चरण 5: अंत में, हम त्रुटि 404 का कारण बनते हैं जब एप्लिकेशन को कुछ भी नहीं मिल सकता है

उदाहरण के लिए, जब MyController से विरासत में मिले हमारे ऋण नियंत्रक को एक अमान्य आईडी पैरामीटर पास किया जाता है:

 // // GET: /Detail/ID public ActionResult Detail(int ID) { Loan loan = this._svc.GetLoans().WithID(ID); if (loan == null) return this.InvokeHttp404(HttpContext); else return View(loan); }

यह बहुत अच्छा होगा यदि आप कम कोड के साथ यह सब लागू कर सकते हैं। लेकिन मेरा मानना है कि यह समाधान बनाए रखना, परीक्षण करना आसान है, और कुल मिलाकर यह अधिक सुविधाजनक है।

दूसरे समाधान के लिए पुस्तकालय

और अंत में: एक पुस्तकालय पहले से ही तैयार है जो आपको ऊपर वर्णित तरीके से त्रुटि हैंडलिंग को व्यवस्थित करने की अनुमति देता है। आप उसे यहाँ पा सकते हैं - github.com/andrewdavey/NotFoundMvc ।

निष्कर्ष

मज़े के लिए, मैंने देखा कि कैसे ऑर्चर्ड में इस समस्या को हल किया गया था। मैं हैरान था और कुछ हद तक निराश था - डेवलपर्स ने इस अपवाद को नहीं संभालने का फैसला किया - उनके अपने 404 त्रुटि पृष्ठ, मेरी राय में, लंबे समय से वेब विकास में मानक बन गए हैं।

अपने आवेदन में, मैंने रूटिंग का उपयोग करके Web.config के माध्यम से त्रुटि हैंडलिंग का उपयोग किया। जब तक एप्लिकेशन का विकास पूरा नहीं हो जाता है, तब तक 404 त्रुटियों से निपटने के लिए ध्यान देना खतरनाक है - आप कभी भी एप्लिकेशन को जारी नहीं कर सकते। अंत में करीब, सबसे अधिक संभावना है, मैं दूसरा समाधान लागू करूंगा।

संबंधित लिंक:

ASP.NET MVC पर मूल 404 त्रुटि पृष्ठ