Server Error Troubleshooting

Summary

• The meeting focused on diagnosing a server error (HTTP 400: Bad Request) encountered on the Conservation International blog page.
• Attendees discussed current server error handling settings and steps required to expose or customize error messages for troubleshooting.
• Action items center on updating configuration files and ensuring appropriate remote error visibility.

Action Items

• ASAP – Web Admin: Update the web.config file to set <customErrors mode="Off"/> to allow remote error details for troubleshooting.
• After fix – Web Admin: Restore error display settings or configure a custom error page using the <customErrors> tag with the defaultRedirect attribute.

Error Diagnosis and Configuration

• The web server is returning a 400 Bad Request error when accessing the specified URL.
• The application is currently configured to hide detailed error messages from remote browsers for security.
• Viewing full error details currently requires logging in directly from the server machine.
• To temporarily expose detailed error messages remotely, the <customErrors> tag in web.config should have mode="Off".
• For ongoing security and user experience, a custom error page can be set up via the defaultRedirect attribute: e.g., <customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>.

Decisions

• Temporarily enable detailed remote errors for debugging — To facilitate troubleshooting, remote error detail will be enabled by setting <customErrors mode="Off"/>, to be reverted after resolving the issue.

Open Questions / Follow-Ups

• What caused the 400 Bad Request error on the blog page?
• Is there a process for notifying stakeholders when error settings are temporarily changed?
• Does the organization have a standardized custom error page design?