Ошибка при перехвате запроса слишком большой
Я использую веб-сервер IIS 8.0 и использую ASP.NET и C#.
У меня есть окно загрузки, где пользователь может загрузить файл на сервер, и после ограничения около 50 МБ на белой странице появляется сообщение:
The page was not displayed because the request entity is too large.
Я хотел бы отобразить более удобную для пользователя страницу с красным уведомлением с надписью "Ошибка при загрузке файла, обратитесь к нам за помощью".
В моем файле codebehind при обработке события нажатия кнопки загрузки я добавил:
try
{
//try to save the file to server
}
catch(Exception ex)
{
//otherwise, set the asp:Label tag text to display error
}
Тем не менее, код в catch Заявление не выполняется. Я думаю, что ошибка может быть связана с IIS и не может быть пойман с этим утверждением кода. Есть ли способ перехватить эту ошибку и отобразить более дружественную страницу с ошибкой?
Спасибо за помощь.
3 ответа
Следующие две ссылки помогли решить мою проблему.
http://www.beansoftware.com/ASP.NET-Tutorials/Custom-Error-Pages.aspx
Если загруженный файл больше, чем разрешено IIS, он никогда не достигнет среды выполнения ASP.NET, и ваша обработка исключений бесполезна.
Вы должны установить uploadReadAheadSize намного выше, чем вы хотите разрешить, в идеале только для определенного URL. Затем проверьте размер загружаемого файла в своем коде и отобразите собственное сообщение.
Если пользователь загружает огромный файл, размер которого больше, чем uploadReadAheadSize, он все равно получает сообщение IIS, но в этом случае вероятность использования большого числа значительно снижается.
Здесь есть множество решений/комментариев, ни одно из которых не затрагивает фундаментальный вопрос. Какая сущность слишком велика? У нас возникла та же проблема, и в конечном итоге мы определили, что объект с ошибкой был объектом состояния представления на странице ASPX. Просто сделать размер maxBufferPoolSize, maxBufferSize и maxReceivedMessageSize чрезвычайно большим — это не совсем правильное решение. Это сработает, но вы только маскируете проблему, и она возникнет в какой-то момент в будущем.
ViewState Веб-приложение не имеет состояния. Это означает, что новый экземпляр страницы создается каждый раз, когда мы делаем запрос к серверу на получение страницы, и после обратного пути наша страница сразу же теряется. Это происходит только из-за одного сервера, все элементы управления веб-страницы создаются, и после прохождения туда и обратно сервер уничтожает все экземпляры. Поэтому, чтобы сохранить значения элементов управления, мы используем методы управления состоянием. Состояние просмотра — это метод сохранения значения страницы и элементов управления между обращениями. Это метод управления состоянием на уровне страницы. Состояние просмотра включено по умолчанию и обычно сериализует данные в каждом элементе управления на странице независимо от того, действительно ли они используются во время обратной передачи.
Решение На нашей веб-странице отображалась сетка записей, которая по запросу пользователя предоставляла доступ к каждой записи в базовом представлении запроса данных. Поскольку записи были добавлены в таблицы за пределами этого представления, набор данных Gridview стал слишком большим, чтобы страница ASPX могла сохранить и вызвать объект состояния представления. Наше решение заключалось в том, чтобы понять бизнес-причины, по которым требовался весь набор данных, и, как выяснилось, в целом требовались данные только за последние 7 дней, а любые дальнейшие действия в прошлом учитывались постоянным отчетом. Как только это было понято, мы просто изменили запрос страницы, ограничив данные за последние 7 дней, обнародовали изменения и проинформировали пользователей. Проблема исправлена.