default document fail (Exception: ManagedPipelineHandler, 0x800703e9)

[KevinKao809]

Hi, all the things works well with smart i18n, just only default document fail. More specific is when I input URL: http://127.0.0.1/, IIS Server return Internal Server Error (500.0), and display below error:

Module ManagedPipelineHandler Notification ExecuteRequestHandler Handler ExtensionlessUrl-Integrated-4.0 Error Code 0x800703e9

If I remove i18n config section from web.config, my default doc (index.html) back to normal.

Any idea ?

Kevin Kao

[turquoiseowl]

I can't remember seeing that before.

Are you able to tell if an exception is being thrown from our HttpModule (i18n.LocalizingModule)? Are you able to provide a stack trace, or even better run in a debugger against the source to see where the exception occurs?

Have you seen this?:

http://www.asptricks.net/2015/06/error-code-0x800703e9-http-error-5000.html

[KevinKao809]

Hello Sir, Follow your suggestion, I run debugging on LocalizingModule, and found that this method be call 12 times (BeginRequest) when context.Request.AppRelativeCurrentExecutionFilePath come with "..\", and finally IIS throw Exception (nothing capture from your code). If I give filename (say /index.html), the method (BeginRequest) only be call 2 times, and without any issue. Kevin Kao Date: Sun, 10 Jan 2016 06:40:23 -0800 From: notifications@github.com To: i18n@noreply.github.com CC: cheeyuankao@outlook.com Subject: Re: [i18n] default document fail (Exception: ManagedPipelineHandler, 0x800703e9) (#246)

I can't remember seeing that before.

Are you able to tell if an exception is being thrown from our HttpModule (i18n.LocalizingModule)? Are you able to provide a stack trace, or even better run in a debugger against the source to see where the exception occurs?

Have you seen this?:

http://www.asptricks.net/2015/06/error-code-0x800703e9-http-error-5000.html

— Reply to this email directly or view it on GitHub.

[KevinKao809]

Hello Sir, I modify source code by add below into method: ProcessIncoming if (urlNonlocalized.Equals("/")) urlNonlocalized = "/index.html"; This can solve my issue, but not a generic approach. Kevin Kao

From: cheeyuankao@outlook.com To: reply@reply.github.com; i18n@noreply.github.com Subject: RE: [i18n] default document fail (Exception: ManagedPipelineHandler, 0x800703e9) (#246) Date: Mon, 11 Jan 2016 12:47:08 +0800

Hello Sir, Follow your suggestion, I run debugging on LocalizingModule, and found that this method be call 12 times (BeginRequest) when context.Request.AppRelativeCurrentExecutionFilePath come with "..\", and finally IIS throw Exception (nothing capture from your code). If I give filename (say /index.html), the method (BeginRequest) only be call 2 times, and without any issue. Kevin Kao Date: Sun, 10 Jan 2016 06:40:23 -0800 From: notifications@github.com To: i18n@noreply.github.com CC: cheeyuankao@outlook.com Subject: Re: [i18n] default document fail (Exception: ManagedPipelineHandler, 0x800703e9) (#246)

I can't remember seeing that before.

Are you able to tell if an exception is being thrown from our HttpModule (i18n.LocalizingModule)? Are you able to provide a stack trace, or even better run in a debugger against the source to see where the exception occurs?

Have you seen this?:

http://www.asptricks.net/2015/06/error-code-0x800703e9-http-error-5000.html

— Reply to this email directly or view it on GitHub.

[turquoiseowl]

Closing this because the problem appears to be specific to your site. Feel free to re-open with further comment.

[jnpwly]

Hi @turquoiseowl. I have just started a new job, and have recommended your tool to them, because it is awesome!

I appeared to have the same the same problem that @KevinKao809 reported a couple of years ago; that is, the initial page request failing with an HTTP Status Code 500.0, and a reported Error Code of 0x800703e9. I followed the instructions on the http://www.asptricks.net/2015/06/error-code-0x800703e9-http-error-5000.html blog post, but this did not alleviate the issue.

When we switched from the i18n.UrlLocalizationScheme.Scheme2 setting to i18n.UrlLocalizationScheme.Void, our problems went away.

Our current thinking is that something in the project is not playing nicely with the way URLs are localised; maybe it's the way the application's routing table is set up (which, at this stage, I don't fully understand, as we have a mix of WebForms, MVC and WebApi2 all smudged into the same webapp project, with liberal use of attributed routing.

We can live with how things are, so we are not stopped from progressing. I thought you might appreciate hearing of a similar situation, just in case someone else comes across it too.

Many thanks for this awesome tool -- very much appreciated!