[Mono-dev] [PATCH] Add HttpNotFoundHandler and HttpNotImplementedHandler
Miguel de Icaza
miguel at novell.com
Mon Nov 2 11:07:51 EST 2009
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.
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
>>> in exception/error handling because of that. Only then the type
>>> can be
>> These handlers need no special treatment. ASP.NET runtime should be
>> 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
>> 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.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list