Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature addition: skipIISCustomErrors #568

Open
wants to merge 22 commits into
base: master
Choose a base branch
from
Open

Conversation

mparq
Copy link

@mparq mparq commented Apr 9, 2017

(see #446 and #476)

This feature will allow a mixed solution to error handling with IIS and iisnode rather than relying <httpErrors existingResponse="PassThrough" />
to work around IIS trying to replace error responses from the node application with custom friendly error pages.

The default mechanism existingResponse="Auto" allows for the following behavior:

  1. If the IHttpResponse::SetStatus method was called by using the fTrySkipCustomErrors flag, the existing response is passed through, and no detailed or custom error is shown.
  2. If the ErrorMode property is set to Custom, the response is replaced.
  3. If ErrorMode is set to Detailed and there is an existing response, the response is passed through.
  4. If ErrorMode is set to Detailed and there is no existing response, the response is replaced with a detailed error.

This feature would allow an opt-in into option 1, where responses returned from the node application through iisnode would call IHttpResponse::SetStatus with the fTrySkipCustomErrors flag set if iisnode is configured with skipIISCustomErrors="true". Empty error responses resulting from internal iisnode errors will not be affected by this, so that those errors can be handled by IIS. This is only really a factor if devErrorsEnabled="false".

This sort of work flow is useful because usually the node application should be gracefully handling and creating friendly/helpful error responses to be passed to the client. Sometimes, existingResponse="PassThrough" is acceptable for this if you never need to do any custom error handling outside of iisnode. However, if you happened to need this, then you are stuck. For example, if you would like to route users of your site to a friendly error page directing them to request the necessary security group accesses they need if they do not pass authentication, then you need to implement custom error routing in the <httpErrors> section of your web config since this sort of error is not under iisnode's purview. But anything other than existingResponse="PassThrough" will interfere with your existing node application error messages.

With this feature, you can set skipIISCustomErrors="true" in iisnode's configuration so that any responses sent back through iisnode from the node application will be passed with the TrySkipIISCustomErrors flag. This will allow these responses to pass through when existingResponse="Auto", while still allowing custom errors to be sent to clients for errors external to iisnode.

rramachand21 and others added 22 commits April 11, 2016 00:49
IHTTPResponse::SetStatus needs to be called with this flag set in
order for iisnode to bypass IIS custom errors when errorMode="Auto"
Users can opt into the fTrySkipCustomErrors flag behavior with skipIISCustomErrors="true".
If this option is not specified, then the default behavior will match the previous behavior.
Internal iisnode errors should probably not set fTrySkipCustomErrors since these are just empty status responses.
Let IIS capture and replace these responses with more detailed messages depending on the custom error mode.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants