[Mono-dev] [PATCH] Add HttpNotFoundHandler and HttpNotImplementedHandler

Miguel de Icaza miguel at novell.com
Mon Nov 2 11:07:51 EST 2009


Hello,

      I think we want to get the patch in for the thing that can be  
referenced from Web.config;   I do not care about the exception class,  
it is too much work to make it remotely useful.

Miguel.

On Nov 2, 2009, at 4:28 AM, Marek Habersack wrote:

> Kornél Pál wrote:
>> Marek Habersack wrote:
>>>> HttpNotImplementedHandler is not used in Web.config and is most
>>>> likely known by much less people but I found it in the prevously
>>>> referenced book so I just implemented that as well to make the
>>>> internal simple handler collection complete.
>>> I don't think we should include it just for the sake of it. If you
>>> want it in, that's fine, but you need to modify all the spots in
>>> System.Web code which throw 404 and make sure there are no  
>>> regressions
>>> in exception/error handling because of that. Only then the type  
>>> can be
>>> included.
>>
>> These handlers need no special treatment. ASP.NET runtime should be  
>> and
>> according to my experiences is able to receive HttpExceptions with
>> status codes from handlers/user code.
> Yes, it is able to do that, but that's not my point. I don't want  
> practically unused internal code
> in System.Web for the sake of matching .NET internals. If you want  
> an internal type like this in
> System.Web, please make some use of it.
>
>> Only 403 and 404 codes are treated specially, that means a more
>> destrictive error page, but that should not make any distinction  
>> based
>> on the origin of the exception, just the status code.
> That's the theory, yes - I'd like to be sure in practice that there  
> are no regressions from
> introducing a new type for 404.
>
>> No maintenance requirements come with these two handlers. They just
>> should be treated just like any other external handler. Their sole
>> purpose is to throw HttpExceptions with the respective status code.
> Once again, that's fine - but if we include them, I want them to be  
> used and not just sit there.
> Code which isn't used is likely to erode with time (even if it's as  
> simple as the code you posted)
> and we want to avoid that.
>
> marek
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



More information about the Mono-devel-list mailing list