ASP.NET - как показать ошибочную страницу при загрузке большого файла (Максимальная длина запроса превысила)?
Если вы используете Babel , то поддержка unicode уже доступна.
Я также выпустил плагин, который преобразует ваш исходный код, чтобы вы могли пишите регулярные выражения типа /^\p{L}+$/. Затем они преобразуются во что-то, что понимают браузеры.
Вот страница проекта плагина: https://github.com/danielberndt/babel-plugin-utf-8-regex
5 ответов
Поскольку Вы говорите, что можно установить maxRequestLength в web.config (переопределяющий 4 МБ по умолчанию machine.config) и если это ограничивает, превышен, Вы обычно получаете ошибку HTTP 401.1.
Для обработки универсальной Ошибки HTTP в прикладном уровне, можно установить раздел CustomError в web.config в разделе system.web:
<system.web>
<customErrors mode=On defaultRedirect=yourCustomErrorPage.aspx />
</system.web>
Каждый раз ошибка, показал, что пользователь будет перенаправлен к Вашей пользовательской ошибочной странице.
Если Вы хотите специализированную страницу для каждой ошибки, можно сделать что-то как:
<system.web>
<customErrors mode="On" defaultRedirect="yourCustomErrorPage.aspx">
<error statusCode="404" redirect="PageNotFound.aspx" />
</customErrors>
</system.web>
И так далее.
Кроме того, Вы могли отредактировать вкладку CustomErrors своих свойств виртуального каталога от IIS для указания на предпочтительные страницы обработки ошибок.
Вышеупомянутое, кажется, не работает на 401.x ошибки - эта статья проекта кодом объясняет обходное решение для, какой, кажется, очень похожая проблема: Перенаправление к пользовательской 401 странице
К сожалению, Вы, вероятно, потребуете IIS7 и поймаете это с пользовательским обработчиком, так как IIS6 никогда не будет доходить до стадии, где она видит размер файла. Это может только знать размер, когда это сделало загрузку или имеет ошибку.
Это - известная проблема в ASP.NET. Другая (хромая) альтернатива должна обработать это ранее в запросе и возможно использовать основанный на флэш-памяти загрузчик. John связывается с несколькими в ссылке ниже.
Обновление: Jon Galloway, казалось, глубже изучил эту проблему, и кажется, что загрузчик RIA является единственной разумной альтернативой, так как IIS, кажется, всегда должен глотать файл И ЗАТЕМ говорить Вам, что это к большому.
Необходимо смочь зафиксировать ошибку в Global.asax - OnError () обработчик. Но к сожалению, Ваш начальный запрос будет закончен, и Вы не сможете представить ту же страницу загрузки с некоторым уведомлением об ошибке пользователю.
Что можно сделать, самое большее должен отобразить дружественную ошибочную страницу с простым пунктом перенаправления из OnError () обработчик и на той странице, чтобы иметь некоторый обратный канал или схожую функциональность для возврата пользователя странице, где он инициировал ошибку во-первых.
Обновление:
Я должен был реализовать точную проверку на загрузку файла недавно и что я придумал, библиотека SWFUpload, которая полностью отвечала моим требованиям и также имеет много дополнительных функций. Я использовал его наряду с оберткой jQuery, обеспеченной Steve Sanderson. Больше деталей может быть найдено здесь.
Точка, та флэш-память может обнаружить размер файла на стороне клиента и реагировать правильно, если этот случай встречен. И я думаю, что это точно, в чем Вы нуждаетесь.
Далее больше можно реализовать проверку обнаружения флэш-памяти, если Вы хотите корректно degerade к собственной загрузке button0 в случае, если у клиента нет флэш-памяти установленной.
Вы могли проверить длину postedfile (FileUpload. PostedFile. ContentLength), чтобы видеть, ли это ниже предела или не и просто показ дружественного сообщения об ошибке при необходимости.
Сергей,
Согласно ответу JohnIdol, вам нужно настроить пользовательскую страницу ошибки для кода состояния 413 . Например:
<customErrors mode="On" defaultRedirect="~/Errors/Error.aspx">
<error statusCode="413" redirect="~/Errors/UploadError.aspx"/>
</customErrors>
Я знаю, потому что мне нужно было решить ту же проблему в клиентском проекте, и это было решение, которое работало для меня. К сожалению, это было единственное решение, которое я нашел ... было невозможно поймать эту конкретную проблему в коде; например, проверка длины опубликованного файла, как предложил snomag, или обнаружение ошибки в global.asax. Как и вы, я пробовал и другие подходы, прежде чем нашел рабочее решение. (на самом деле я в конечном итоге нашел это где-то в сети, когда работал над своей проблемой).
Надеюсь, это поможет.