Что такое код asp httperrors


ASP.NET Web API удаляет HttpError из ответов

Я создаю службу RESTful с помощью веб-API ASP.NET.

Моя проблема касается HttpErrors, которую веб-API возвращает пользователю, когда что-то пойдет не так (например, 400 Bad Request или 404 Not Found).

Проблема заключается в том, что я не хочу получать сериализованный HttpError в ответном контенте, поскольку он иногда предоставляет слишком много информации, поэтому он нарушает правила безопасности OWASP, например:

В качестве ответа я, конечно, получаю 400, но со следующей информацией о содержании:

Что-то вроде этого не только указывает на то, что мой WebService основан на технологии ASP.NET WebAPI (что не так уж плохо), но также дает некоторую информацию о моих пространствах имен, именах методов, параметрах и т.д.

Я попытался установить IncludeErrorDetailPolicy в Global.asax

Да, это как-то хорошо, теперь результат не содержит раздел MessageDetail, но все-таки я не хочу получать этот HttpError вообще.

Я также создал свой собственный DelegatingHandler, но он также влияет на 400 и 404, которые я сам генерирую в контроллерах, которых я не хочу.

Мой вопрос: Есть ли удобный способ избавиться от сериализованного HttpError из содержимого ответа? Все, что я хочу, чтобы пользователь возвращался к своим плохим запросам, — это код ответа.

asp.net asp.net-web-api http-error response

2 ответа

1 Badri [2013-07-11 15:56:00]

Я считаю, что ваш подход к использованию обработчика сообщений правильный, потому что независимо от компонента в конвейере веб-API, который устанавливает код состояния в 4xx, обработчик сообщения может очистить тело ответа. Однако вы хотите различать те, которые вы явно задали, и те, которые установлены другими компонентами. Вот мое предложение, и я признаю, что это немного хаки. Если вы не получите другого лучшего решения, попробуйте это.

В ваших классах ApiController , когда вы бросаете HttpResponseException , установите флаг в свойствах запроса, например.

В обработчике сообщений проверьте свойство и не очистите тело ответа, если свойство установлено.

Вы можете скомпоновать это немного, добавив метод расширения в HttpRequestMessage, чтобы ни ApiController , ни обработчик сообщений ничего не знали о жестко закодированной строке «myException», которую я использовал выше.

Как насчет использования пользовательского IHttpActionInvoker? В принципе, вам просто нужно отправить пустой HttpResponseMessage.

HTTP Errors

Overview

The element allows you to configure custom error messages for your Web site or application. Custom error messages let you provide a friendly or a more informative response by serving a file, returning another resource, or redirecting to a URL when visitors to your site cannot access the content they requested. For example, you might want to customize each of the error message pages for your Web site to have the same look and feel as the rest of your site.

The element contains a collection of elements, each of which defines an error message that IIS uses to respond to specific HTTP errors. You can add custom error messages to IIS by adding an element to the element in the Web.config file for your site, application, or URL. Each element uses the responseMode attribute to specify whether IIS serves static content, dynamic content, or redirects to a separate URL in response to an error.

You can use the element to remove a specific error message from the collection of error messages your site or application inherits from a higher level in the IIS configuration hierarchy. Also, you can use the element to remove all HTTP error messages from the collection of HTTP error messages that your site or application inherits.

The element also contains attributes that configure IIS 7 to process requests that cause errors. The existingResponse attribute defines what IIS 7 does to an existing response when the server returns an HTTP error status code. The defaultPath attribute defines the path to a customer error page if you choose specify File for the responseMode attribute in an element.

The detailedMoreInformationLink attribute specifies a link to more information about a particular error.

The element also can contain an errorMode attribute that you can use to control the level of detail that IIS returns to a browser when an HTTP error occurs. You can set the errorMode attribute to DetailedLocalOnly, which is the default setting, or you can set it to Custom or Detailed. If you specify DetailedLocalOnly, or if you do not specify an errorMode value, IIS returns detailed error information only to the browser on the local server and a custom error message to a browser on an external computer. If you set the errorMode value to Custom, IIS returns only custom error messages to all requesting browsers. If you set the errorMode value to Detailed, IIS returns detailed error information to all requesting browsers. The default DetailedLocalOnly value allows you to troubleshoot HTTP errors on the local server while not exposing sensitive information to external browsers.

By default, IIS serves error messages defined in files stored in the %SystemRoot%\Help\IisHelp\Common folder. You can create a custom error message for users and configure IIS to return this page whenever it encounters a specific HTTP error on your site.

Compatibility

Version Notes
IIS 10.0 The element was not modified in IIS 10.0.
IIS 8.5 The element was not modified in IIS 8.5.
IIS 8.0 The element was not modified in IIS 8.0.
IIS 7.5 The allowAbsolutePathsWhenDelegated attribute was added to the element in IIS 7.5
IIS 7.0 The element was introduced in IIS 7.0.
IIS 6.0 The element replaces the IIS 6.0 HttpErrors property of the IIsWebService metabase object.

Setup

The element is included in the default installation of IIS 7.

How To

How to add a custom error page

Open Internet Information Services (IIS) Manager:

If you are using Windows Server 2012 or Windows Server 2012 R2:

  • On the taskbar, click Server Manager, click Tools, and then click Internet Information Services (IIS) Manager.

If you are using Windows 8 or Windows 8.1:

  • Hold down the Windows key, press the letter X, and then click Control Panel.
  • Click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.

If you are using Windows Server 2008 or Windows Server 2008 R2:

  • On the taskbar, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

If you are using Windows Vista or Windows 7:

  • On the taskbar, click Start, and then click Control Panel.
  • Double-click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.
  • In the Connections pane, expand the server name, expand Sites, and then navigate to the Web site or application that you want to configure custom error pages for.
  • In the Home pane, double-click Error Pages.
  • In the Actions pane, click Add.

  • In the Add Custom Error Page dialog box, under Status code, type the number of the HTTP status code for which you want to create a custom error message.

    In the Response Action section, do one of the following:

    • Select Insert content from static file into the error response to serve static content, for example, an .html file, for the custom error.
    • Select Execute a URL on this site to serve dynamic content, for example, an .asp file for the custom error.
    • Select Respond with a 302 redirect to redirect client browsers to a different URL that contains the custom error file.

    In the File path text box, type the path of the custom error page if you chose Insert content from static file into the error response or the URL of the custom error page if you use either the Execute a URL on this site or Respond with a 302 redirect, and then click OK.

    If you select Execute a URL on this site , the path must be a relative path. If you select Respond with a 302 redirect , the URL must be an absolute URL.

    Configuration

    You can configure the element at the server level in the ApplicationHost.config file and at the site and application level in the appropriate Web.config file.

    Attributes

    Attribute Description
    allowAbsolutePathsWhenDelegated Optional Boolean attribute.

    When set to true, absolute paths are allowed for custom error pages when the section is delegated. When set to false, only paths that are relative to the site root are allowed.

    The default value is false . defaultPath Optional string attribute.

    Specifies the default path of the custom error page. The type of path is determined by the defaultResponseMode attribute. If you choose File, the file path is returned. If you choose either the ExecuteURL or Redirect path type, the URL of the custom error page is returned. defaultResponseMode Optional enum attribute.

    Specifies how custom error content is returned.

    The defaultResponseMode attribute can be one of the following possible values; the default is File .

    Value Description
    File Serves static content, for example, a .html file for the custom error. If responseMode is set to File, the path value has to be a file path.

    The numeric value is 0 .

    ExecuteURL Serves dynamic content, for example, a .asp file for the custom error. If responseMode is set to ExecuteURL, the path value has to be a server relative URL.

    The numeric value is 1 .

    Redirect Redirects client browsers to a different URL that contains the custom error file. If responseMode is set to Redirect, the path value has to be an absolute URL.

    The numeric value is 2 .

    detailedMoreInformationLink Optional string attribute.

    Specifies a link, shown at the bottom of the page, to a page with more detailed information about a particular error. You can use this property to point end users to a custom location for error information. The status, sub-status, HRESULT and message ID are sent as part of the query string.

    The default value is https://go.microsoft.com/fwlink/?Link >. errorMode Optional enum attribute.

    Specifies whether HTTP errors are enabled.

    The errorMode attribute can be one of the following values; the default is DetailedLocalOnly .

    Value Description
    DetailedLocalOnly Returns detailed error information if the request is from the local computer, and returns a custom error message if the request is from an external computer.

    The numeric value is 0 .

    Custom Replaces the error that the module or server generates with a custom page that you specify. This mode is useful in providing friendlier error messages to end users.

    Note: This setting turns off detailed errors, even for local requests.

    The numeric value is 1 .

    Detailed Sends detailed error information back to the client. This mode is useful for testing and debugging Web sites and applications.

    The numeric value is 2 .

    existingResponse Optional enum attribute.

    Specifies what happens to an existing response when the HTTP status code is an error, i.e. response codes >= 400.

    The existingResponse attribute can be one of the following values; the default is Auto .

    Value Description
    Auto Leaves the response untouched only if the SetStatus flag is set.

    The numeric value is 0 .

    Replace Replaces the existing response even if the SetStatus flag is set.

    The numeric value is 1 .

    PassThrough Leaves the response untouched if an existing response exists.

    The numeric value is 2 .

    Child Elements

    Element Description
    error Optional element.

    Adds an HTTP error to the collection of HTTP errors. remove Optional element.

    Removes a reference to an HTTP error from the HTTP error collection. clear Optional element.

    Removes all references to HTTP errors from the HTTP error collection.

    Configuration Sample

    The following configuration example, when included in the Web.config file for a Web site or application, uses the errorMode attribute to only allow detailed error messages to appear on the local computer. It also uses the defaultResponseMode attribute to set the response mode for the site or application. The sample then removes the inherited error message for the 500 status code. Next, it sets the prefixLanguageFilePath attribute to the directory where IIS should search of a new custom error page, and sets the path attribute to 500.htm, the file that contains the custom error message.

    Sample Code

    The following examples adds a new file for all status code 404 errors with a substatus of 5, which IIS returns for «URL Sequence Denied» errors. In these examples, the prefix path is set to «%SystemDrive%\inetpub\custerr», and the file name is specified as «404.5.htm».

    MVC ASP.NET -Ошибка HTTP Error 404.7 и отсутствующий файл applicationHost.configі?

    Всем привет, возникла данная ошибка —

    Microsoft рекомендует исправлять это следующим образом Решение от Microsoft
    , но проблема в том , что по пути указанном в статье

    У меня нет ни папки \config , ни самого файла applicationHost.configі — в который они предлагают вносить спасительные изменения для решения проблемы.

    • Вопрос задан более двух лет назад
    • 88 просмотров

    Сдвинулся с мертвой точки — помогло следующее:

    — Т.е «тупо» выставил фильтры для расширения файлов — удалив их с помощью remove и выставил allowUnlisted=»true» — пресловутые инструкции от Microsoft, указанные мною выше — не помогают, а только мешают. Теперь выдает ошибку


    Собственная страница ошибки 404 на ASP.NET MVC

    При разработке проекта на ASP.NET MVC возникла необходимость сделать собственную страницу ошибки 404. Я рассчитывал, что справлюсь с этой задачей за несколько минут. Через 6 часов работы я определил два варианта ее решения разной степени сложности. Описание — далее.

    В ASP.NET MVC 3, с которой я работаю, появились глобальные фильтры. В шаблоне нового проекта, уже встроено ее использование для отображения собственной страницы ошибок (через HandleErrorAttribute). Замечательный метод, только он не умеет обрабатывать ошибки с кодом 404 (страница не найдена). Поэтому пришлось искать другой красивый вариант обработки этой ошибки.

    Обработка ошибки 404 через Web.config

    Платформа ASP.NET предоставляет возможность произвольно обрабатывать ошибки путем нехитрой настройки файла Web.config. Для это в секцию system.web нужно добавить следующий код:

    При появлении ошибки 404 пользователь будет отправлен на страницу yoursite.ru/Errors/Error404/?aspxerrorpath=/Not/Found/Url. Кроме того, что это не очень красиво и удобно (нельзя отредактировать url), так еще и плохо для SEO — статья на habr.ru.
    Способ можно несколько улучшить, добавив redirectMode=«ResponseRewrite» в customErrors:

    В данном случае должен происходить не редирект на страницу обработки ошибки, а подмена запрошенного ошибочного пути содержимым указанной страницы. Однако, и здесь есть свои сложности. На ASP.NET MVC этот способ в приведенном виде не работает. Достаточно подробное обсуждение (на английском) можно прочитать в топике. Кратко говоря, этот метод основан на методе Server.Transfer, который используется в классическом ASP.NET и, соответственно, работает только со статическими файлами. С динамическими страницами, как в примере, он работать отказывается (так как не видит на диске файл ‘/Errors/Error404/’). То есть, если заменить ‘/Errors/Error404/’ на, например, ‘/Errors/Error404.htm’, то описанные метод будет работать. Однако в этом случае не получится выполнять дополнительные действия по обработке ошибок, например, логирование.
    В указанном топике было предложено добавить в каждую страницу следующий код:

    Этот способ работает только с IIS 7 и выше, поэтому проверить этот метод не удалось — используем IIS 6. Поиски пришлось продолжить.

    Танцы с бубном и Application_Error

    Если описанный выше метод применить по каким-либо причинам не удается, то придется писать больше строк кода. Частичное решение приведено в статье.
    Наиболее полное решение «с бубном» я нашел в топике. Обсуждение ведется на английском, поэтому переведу текст решения на русский.
    Ниже приведены мои требования к решению проблемы отображения ошибки 404 NotFound:

    • Я хочу обрабатывать пути, для которых не определено действие.
    • Я хочу обрабатывать пути, для которых не определен контроллер.
    • Я хочу обрабатывать пути, которые не удалось разобрать моему приложению. Я не хочу, чтобы эти ошибки обрабатывались в Global.asax или IIS, потому что потом я не смогу сделать редирект обратно на мое приложение.
    • Я хочу обрабатывать собственные (например, когда требуемый товар не найден по ID) ошибки 404 в едином стиле.
    • Я хочу, чтобы все ошибки 404 возвращали MVC View, а не статическую страницу, чтобы потом иметь возможность получить больше данных об ошибках. И они должны возвращать код статуса 404.

    Я думаю, что Application_Error в Global.asax должен быть использован для целей более высокого уровня, например, для обработки необработанных исключений или логирования, а не работы с ошибкой 404. Поэтому я стараюсь вынести весь код, связанный с ошибкой 404, вне файла Global.asax.

    Шаг 1: Создаем общее место для обработки ошибки 404

    Это облегчит поддержку решение. Используем ErrorController, чтобы можно было легче улучшать страницу 404 в дальнейшем. Также нужно убедиться, что контроллер возвращает код 404!

    Шаг 2: Используем собственный базовый класс для контроллеров, чтобы легче вызывать метод для ошибки 404 и обрабатывать HandleUnknownAction

    Ошибка 404 в ASP.NET MVC должна быть обработана в нескольких местах. Первое — это HandleUnknownAction.
    Метод InvokeHttp404 является единым местом для перенаправления к ErrorController и нашему вновь созданному действию Http404. Используйте методологию DRY!

    Шаг 3: Используем инъекцию зависимостей в фабрике контроллеров и обрабатываем 404 HttpException

    Например, так (не обязательно использовать StructureMap):
    Пример для MVC1.0:

    Пример для MVC2.0:

    Я думаю, что лучше отлавливать ошибки в месте их возникновения. Поэтому я предпочитаю метод, описанный выше, обработке ошибок в Application_Error.
    Это второе место для отлова ошибок 404.

    Шаг 4: Добавляем маршрут NotFound в Global.asax для путей, которые не удалось определить нашему приложению

    Этот маршрут должен вызывать действие Http404 . Обратите внимание, что параметр url будет относительным адресом, потому что движок маршрутизации отсекает часть с доменным именем. Именно поэтому мы добавили все эти условные операторы на первом шаге.

    Это третье и последнее место в приложении MVC для отлова ошибок 404, которые Вы не вызываете самостоятельно. Если здесь не удалось сопоставить входящий путь ни какому контроллеру и действию, то MVC передаст обработку этой ошибки дальше платформе ASP.NET (в файл Global.asax). А мы не хотим, чтобы это случилось.

    Шаг 5: Наконец, вызываем ошибку 404, когда приложению не удается что-либо найти

    Например, когда нашему контроллеру Loan, унаследованному от MyController, передан неправильный параметр ID:

    Было бы замечательно, если бы можно было все это реализовать меньшим количеством кода. Но я считаю, что это решение легче поддерживать, тестировать, и в целом оно более удобно.

    Библиотека для второго решения

    Ну и на последок: уже готова библиотека, позволяющая организовать обработку ошибок описанным выше способом. Найти ее можно здесь — github.com/andrewdavey/NotFoundMvc.

    Заключение

    Интереса ради я посмотрел, как эта задача решена в Orchard. Был удивлен и несколько разочарован — разработчики решили вообще не обрабатывать это исключение — собственные страницы ошибок 404, на мой взгляд, давно стали стандартом в веб-разработке.

    В чем разница между customErrors и httpErrors?

    В чем разница между customErrors и httpErrors разделами сети. Конфигурационный файл в ASP. NET MVC приложений?

    Каковы рекомендации по использованию каждого раздела?

    4 ответов

    * Обновлено в апреле 2020 г.

    Атрибут customErrors используется, когда. Сетевой код вызывает исключение (404, 403, 500 и т. д.), а атрибут httpErrors используется, когда сам IIS создает исключение.

    • / myfakeextensionslessurl — & gt; httpErrors 404
    • / myfakeaspsx. aspx — & gt; customErrors 404
    • / myfakeimage. jpg — & gt; httpErrors 404
    • / throw500. apx — & gt; customErrors 500
    • / throw500 — & gt; customErrors 500

    Есть много ловушек, пытающихся настроить это правильно. Так что, если вы ищете быстрый пример, лучшие 2 варианта у вас есть:

    Пример 1. Использование HTML-страниц

    Пример 2: использование страниц aspx

    И на страницах ошибок aspx вам нужно сделать что-то вроде этого (пример страницы 404):

    Примечание: Использование расширений меньше URL в разделе customErrors невозможно! . (без взлома)

    Обходной путь — отключить пользовательские ошибки и разрешить ошибкам http обрабатывать пользовательскую страницу. Друг создал такую ​​настройку, когда найду время, поделюсь кодом.

    Фон

    Хорошая пользовательская страница ошибки будет:

    1. Показать реальное исключение при локальном посещении страницы проблемы
    2. Показывать пользовательскую страницу при удаленном посещении страницы проблемы
    3. Не будет перенаправлять, а просто отображать содержимое страницы с ошибкой (по причинам SEO)
    4. Покажет правильный код статуса

    Итак, чтобы уточнить некоторые параметры в нашей конфигурации:

    1. customErrors mode = «RemoteOnly». Вы можете указать здесь: On, Off, RemoteOnly. Вкл = Показать всегда пользовательские страницы ошибок, Выкл = Показать всегда настоящую ошибку, RemoteOnly = Показать локально ошибку, но показать страницу пользовательских ошибок удаленно. Поэтому мы хотим RemoteOnly для утверждения 1
    2. customeErrors redirectMode = «ResponseRewrite». Вы можете указать здесь: Response Redirect, ResponseRewrite. Модус ResponseRedirect перенаправит страницу с ошибкой на пользовательскую страницу с ошибкой. Для сканера ссылок (seo) это приведет к 302 — & gt; 500. Хотя вы хотите, чтобы сканер ссылок получил просто 500 ошибок.
    3. httpErrors errorMode = «DetailLocalOnly», это эквивалент режима customErrors. Доступные параметры: Пользовательский, Подробный, ПодробныйЛокальный, только


    Отказ от ответственности: Это из моего опыта и не доказанный факт.

    Оба используются для определения обработки ошибок для веб-сайта, но разные программы ссылаются на разные элементы конфигурации

    customErrors — это устаревший (обратно совместимый) элемент, используемый Visual Studio Development Server (он же). ВСДС или Кассини).

    httpErrors — это новый элемент, который используется только IIS7.

    Это подчеркивает возможные проблемы при разработке ASP. NET сайты при использовании VSDS вместо локальных IIS.

    Кроме того, см. Этот пост сам о том, как обрабатывать сообщения об ошибках с IIS7, если вы хотите иметь полный контроль над выводом ошибки.

    Резюме:

    • Разработка в VSDS — использование customErrors
    • Публикация сайта в IIS6 — использование customErrors
    • Публикация сайта по IIS7 — используйте httpErrors .

    и если вы разрабатываете с VSDS , но публикуете на IIS7 , то, я думаю, вам понадобятся оба.

    против

    • по-прежнему доступны в IIS7 +
    • указать пользовательские страницы ошибок для запросов, обрабатываемых ASP. NET
    • обрабатывает только запросы в ASP. NET приложение
    • статические файлы, такие как HTML-файлы или каталоги («дружественные»), URL-адреса не обрабатываются
    • введен в IIS7
    • указать пользовательские страницы ошибок для запросов, обрабатываемых IIS
    • обрабатывает запросы в ASP. Приложение NET И / ИЛИ обрабатывает запросы вне — ASP. NET приложение *
    • обрабатываются все файлы и URL *

    Примечание: больше не нужно использовать customErrors

    Источник цитирования: Пользовательские 404 и страницы ошибок в ASP. NET (отличная статья)

    ExecuteURL обслуживает динамическое содержимое, например. Страница aspx (значение path должно быть относительным URL-адресом сервера ):

    File обслуживает пользовательский файл ошибок, такой как. html page:

    Ссылка: Ошибки HTTP (www. МИБ. нетто)

    для более подробной информации, читайте www. МИБ. чистая ссылка выше

    Раздел ошибок в веб-конфигурации предназначен для обеспечения пользовательского подхода к обработке ошибок http. В системе разделов есть два раздела, один customErrors. web и другие httpErrors внутри системы разделов. веб-сервер (как указано ниже)

    customErrors: Этот раздел использовался до введения IIS 7, IIS 6 5 и до полного использования этого раздела для обработки пользовательских ошибок http в соответствии с кодом состояния http.

    httpErrors: IIS 7 и более поздние версии используют этот раздел, а также раздел customErrors для обработки пользовательских ошибок http на основе их расширений файлов, если запрошенное расширение страницы регистрируется в ISAPI dll (. aspx, ashx,. asmx. svc и т. д.) как индекс. aspx, а затем IIS выбирает настройку из раздела customeErrors , иначе она выбирает настройку из httpErrors (режим размещения IIS 7 должен быть настроен как интегрированное, а не классическое настроение)

    Коды ответов сервера: исчерпывающий список кодов ошибок HTTP

    Довольно часто вы можете столкнуться с такими ошибками, как 404 и 301, но есть много кодов статуса HTTP, с которыми вы, вероятно, не знакомы.

    Некоторые из них напрямую связаны с сервером или с клиентом, а некоторые уже не актуальны, поэтому вы вряд ли увидите их в реальной жизни, но ради интереса и базовых знаний их можно исследовать.

    Таблица внизу поможет быстро найти ответ по любому коду. Это очень актуально, когда вы увидели на сайте не знакомый статус и важно понять и решить проблему очень быстро.

    1xx информационные коды

    100 Continue Server Code (Продолжение кода сервера)
    Код 100 Continue обозначает «нормальную работу». Он указывает, что пользователь сделал качественный запрос, и сервер начал его обрабатывать. Это временный код статуса HTTP, появляющийся лишь в тех отдельных случаях, когда пользователь ожидает окончательный ответ со стороны сервера. Он возникает только после отправки последнего пакета данных.

    Когда такой статус-код можно использовать? Это внутренний статус, бывают случаи, когда он не появляется, особенно если пользователю уже удалось получить некоторые данные из сервера. Это что-то похожее на месседж, в котором сообщается, что соединение установилось качественно, и вы можете зайти на сайт. Отправьте данные, но не забудьте закрыть дверь, когда вы закончите (подразумевается код окончательного ответа).

    101 Switching Protocols (Переключение протоколов)
    Вероятно, это один из простейших кодов сервера. Он означает, что пользователь попросил переключить используемый тип протокола, и веб-сервер согласился на такой шаг.
    Когда вы можете его применить? Если осуществляется переход на новую версию HTTP из старой версии протокола. Такой запрос будет выполняться только в том случае, если существует более подходящий протокол (другими словами, если есть более новая версия HTTP).

    102 Processing (Обработка)
    Поскольку запрос WebDAV (протокол передачи), кроме основного запроса может включать и ряд других подзапросов, подразумевая также и файловые операции, то для его выполнения может потребоваться больше времени.
    Когда можно использовать этот код? Он создается для того, чтобы уведомить пользователя и обнулить таймер. Дальше будет активировано ожидание следующей директивы в стандартном режиме, поскольку обработка запросов способна затянуться по времени.

    2xx Success (Успех)

    Ответы такого типа уведомляют пользователей о принятии и успешной обработке запросов клиента. Зависимо от того, какой сейчас текущий статус сервера, он все равно может отправлять заголовки и основную часть сообщения. Другими словами, этот тип ответов сервера предполагает, что действие, о котором клиент делал запрос, без сложностей приняли в обработку.

    200 OK
    Код состояния 200, наверное, является наиболее популярным, но в то же время очень неприметным в плане использования. Он указывает, что передача данных между сервером и пользователем подошла к завершению, и все прошло так, как должно.
    Когда этот код нужно использовать? Постоянно!

    201 Created (Создан)
    В связи с успешным выполнением запроса создался новый ресурс. К примеру, благодаря запросу юзера сгенерирован такой ранее не существующий веб-ресурс, как новая страница. Исходной сервер настроен так, что обязан создать ресурс еще до отправки 201 кода. Если документ не может быть сгенерирован своевременно, сервер использует в качестве альтернативы код 202 (принят).

    202 Accepted (Принят)
    Текущий запрос был передан в стадию обработки, но в силу объективных факторов является незавершенным. Запрос к серверу может быть не завершенным, это зависит от факта, успешно ли прошла обработка и не отклонили ли его.

    В каких случаях подобный ответ может быть использован? Когда сервер не в состоянии выполнять запрос в тот момент, когда он делается. Принудительное выполнение запроса не предусматривается, а клиент не должен ожидать пока сообщение будет передано окончательно, поскольку высока вероятность длительного процесса обработки.

    203 Non-Authoritative Information (Недостоверная информация)
    Серверу удалось полностью обработать запрос, но передаваемые данные не были взяты из первостепенного источника (резервная копия, другой сервер и т. д.) и поэтому информация может быть нерелевантной. Этот код имеет большое сходство с 200 серверным ответом, но указывает, что данные не были получены из источника.

    Когда применяют подобный ответ сервера? Ним можно заменить 200 код, если отправитель имеет веские основания полагать, что заголовки ответов из внешнего источника отличаются от тех, которые были предоставлены исходным сервером.

    204 No Content (Нет контента)
    Этот код является ответом сервера, который указывает, что запрос получили и поняли. Но при этом не существует данных, которые могут быть отправлены пользователю. В основном такой код используется для активации скриптов без необходимости внесения изменений в веб-документ. Нужно, чтобы указанный код не содержал основного сообщения, и он должен быть вставлен в первую строку с кодом, которая является доступной сразу после заголовка.

    Когда применяется такой код? Он используется в первую очередь, когда вы должны вводить или выполнять любые действия без необходимости в обновлении ресурса (например, страницы).


    205 Reset Content (Сброс контента)
    Код обозначает успешную обработку запроса сервером c отсутствующим возвратом контента. В отличие от 204 кода, этот ответ требует, чтобы документ был обновлен.

    Когда может применяться такой код? Обычно он используется в случаях, заполнения пользователем формы, и отправки сервером браузеру запроса на очистку этой формы. Он имеет сходство с 204 кодом, но выдвигает требование к пользователю по сбросу документа после завершения обработки. К примеру, требуется провести очистку HTML-формы после верификации.

    206 Partial Reset (Частичный сброс)
    Сервер возвращает только часть контента, которая соответствует заголовку, отправленному клиентом. В основном его используют расширенные инструменты кэширования. Такое бывает, когда пользователь хочет получить лишь небольшую часть контента страницы, а сервер в своем ответе предоставляет данные только для этой части страницы.

    Каковы способы применения этого кода? Преимущественно этот код используется из-за запроса If-Range, применимого в мощных кеш-валидаторах. Обращение также должно включать заголовки областей, которые используются в качестве параметров для области возвращаемой информации.

    207 Multi-Status (Мультистатус)
    Сервер параллельно предоставляет результаты нескольких независимых операций, которые включаются в тело сообщения в виде XML-документа.

    3xx Редирект

    Этот класс ответов сервера является индикатором дальнейших действий, которые следует выполнить агенту пользователя для того, чтобы закрыть запрос. Пользователи могут либо предпринимать действия, либо посылать разные запросы к серверу.

    300 Multiple Choices (Множественный выбор)

    Этот код предоставляет пользователю данные о том, что веб-ресурс переместили, и поэтому сервер предлагает пользователю доступные альтернативы, из которых он может выбрать самый релевантный веб-ресурс.

    В каких случаях будет применен этот ответ сервера? В типичном случае, его можно наблюдать, если сервер получил информацию, что URL-адрес, предоставленный пользователем (иными словами, браузер пользователя), имеет неподходящий индекс и предлагает дополнительный выбор. В обычном порядке такое происходит, когда пользователи применяют URL-адрес к каталогу не последнего уровня, а сервер предлагает им выбор доступных документов или директории последующего уровня.

    301 Moved Permanently (Удален навсегда)
    Это общий запрос пользователя, который означает, что запросы на этот ресурс (а также запросы, которые последуют за ним) следует перенаправить на указанный URL.

    Когда он используется? Когда страница потеряна, больше не существует, или линк, ведущий на внешний документ, больше неработоспособен. 301 редирект дает пользователю понять, что запрошенный ресурс переместили. В основном он выполняется с помощью файла .htaccess, который доступен на серверах Apache.

    302 Found (Найден)
    Этот код говорит пользователю, что местоположение запрашиваемого веб-документа было временно изменено, а код состояния 302 включает данные о новом размещении, к которому пользователь может делать запрос.

    Где такой код может применяться? Он имеет несколько форматов использования, большинство из которых соответствуют первоначальному предназначению кода. А вначале он был базовым методом создания временной переадресации. Однако, на сегодняшний день существует несколько других – этичных и неэтичных способов его использования.

    303 See Other (Смотреть другой)
    Он является индикатором того, что искомый ресурс можно найти по URL-адресу, который отличный от того, что указан в запросе. Это не обязательно значит, что ресурс был перемещен. Этот код только предоставляет адрес, который должен запрашиваться при аналогичном ответе.

    Когда может применяться этот код? Этот способ в основном существует, чтобы позволить выходным файлам POST-активированных скриптов перенаправлять агента пользователя на избранный веб-ресурс.

    304 Not Modified (Не изменен)
    304 означает, что пользователь запрашивает документ / ресурс только тогда, когда он был изменен с момента последних обновлений кеша этого документа.

    В каких случаях может применяться этот код? Если ответ сервера сообщает вам, что параметры документа If-Modified-Since или If-Match не изменились со времени генерирования последнего кеша. Тогда нет нужды повторно отправлять ресурс на проверку.

    305 Use Proxy (Использовать прокси)
    305 код дает понять пользователю, что доступ к запрашиваемому ресурсу осуществим только через прокси-сервер, указанный в ответе.
    Когда он показывается? Он часто отображается в связи с мерами безопасности и обеспечивает доступ к запрашиваемым URL-адресам.

    306 Switch Proxy (Переключить прокси)
    Изначально он означал, что «последующие запросы должны использовать указанный прокси», но в настоящее время не используется.

    307 Temporary Redirect (Временный редирект)
    Такой код отображается, если открываемый ресурс временно используется для другого URL-адреса, который также содержится в ответе. 307 немного отличается от 302 кода – он является его более конкретной версией.

    Когда он используется? Он выводится почти в аналогичных ситуациях, что и при 302, но пользователь должен продолжать запрашивать исходный URL-адрес при следующих запросах или до того времени, пока не будет выведен другой статус сервера.

    4хх Ошибка клиента

    Класс ответов 4xx указывает на ошибки на стороне клиента или тот факт, что местоположение никогда (или уже) не существовало.

    400 Bad Request (Плохой запрос)
    Запрос не обрабатывается правильно в связи с синтаксической ошибкой.
    Для чего предназначен этот код? Если пользователь делает запрос на информацию, но при этом пренебрегает протокольными правилами передачи гипертекста. Запрос не следует делать повторно без надлежащих перемен в синтаксисе.

    401 Unauthorized (Неавторизирован)
    Он имеет отношение к запросу ресурса, который нуждается в авторизации. Код 401 информирует, что предварительную авторизацию отклонили, поскольку переданные пользовательские данные были неверные.

    Когда он отображается? В случаях, если пользователь делает запрос и использует при этом некорректные входные данные для авторизации (среди них, логин и пароль).

    402 Payment Required (Требуется оплата)
    Этот код сервера забронирован на будущее. Но, изначально предполагалось, что такой статус можно будет использовать при расчетах специальными формами электронных денег. Но ему так и не нашлось применения.

    Какова сфера применения этого кода? Старый сервис Apple MobileMe сообщал об 402-ошибке, если аккаунт пользователя в MobileMe подозревался в любой форме злоупотреблений его ресурсами. Также видеохостинг Youtube использует этот статус, если некий IP-адрес использует чрезмерно большое количество запросов. Поэтому пользователю приходится ввести CAPTCHA.

    403 Forbidden (Запрещен)
    Пользователь пробует добиться доступа к веб-ресурсу, на который у него нет прав, а авторизация здесь никак не может помочь.
    Что насчет применения этого кода? Он используется, когда сервер может понять запрос, но не разрешает выполнить его, поскольку у клиента имеются ограничения доступа к текущему разделу. Обычно такое наблюдается, если веб-ресурс не предназначен для открытого доступа.

    404 Not Found (Не найден)
    Большинство пользователей знакомо с 404 ошибкой. Она указывает на то, что искомый ресурс невозможно найти, но в будущем – когда он может появиться там – к нему можно получить доступ. Также здесь разрешаются все следующие обращения от клиента. Но в большом количестве таких случаев используется код редиректа класса 3xx, и пользователь перенаправляется на альтернативный ресурс или местоположение.
    Когда демонстрируется этот код? Довольно часто, особенно если страницу удалили или переместили. Часто в таких случаях сервер в автоматическом режиме генерирует доступную страницу с ошибкой 404.

    405 Method Not Allowed (Метод не разрешен)
    Метод, посредством которого осуществляется запрос к ресурсу, является недоступным. Иными словами, появляется ошибка при попытке использовать функцию в формате GET, тогда как требуется ввод данных через метод POST (либо с помощью метода PUT с веб-документами только для чтения).

    Когда появляется такой статус-код? Ошибки 405 выходят через их отношение со специфическими объектами страницы, для которых и выполнялось обращение к серверу. К примеру, если часть запроса скрипта имеет отличия с запросом пользователя, подразумевавшего применение этого скрипта.

    406 Not Acceptable (Недопустимо)
    Запрашиваемый ресурс имеет возможность генерировать только тот контент, который не может использоваться в Accept-хедерах самого запроса. Браузер может обеспечить сервер характеристиками данных, которые будут приниматься из сервера.

    В каких случаях такой код может быть использован? В ситуациях, когда форма файла ресурса, который запрашивается не подходит под формат, доступный для распознавания пользователем. Речь здесь идет прежде всего о языке программирования, а не о английском!

    407 Proxy Authentication Required (Нужна авторизация прокси)
    Как и статус-код 401, значение 407 обозначает, что клиенту следует предварительно авторизоваться через прокси-сервер. Для выполнения этого действия и осуществления процесса авторизации, прокси-сервер должен вернуть поле с заголовком Proxy-authenticate, которое отвечает стандартам, предъявляемым сервером.
    Когда появляется этот статус-код? В случаях, если сервер «убежден», что запрос данных от клиента является правильным, но получить доступ к веб-ресурсу возможно лишь через авторизацию с помощью прокси-сервера.

    408 Request Timeout (Тайм-аут запроса)
    Истекло время ожидания сервером ретрансляции от клиента.
    Когда такой статус-код применяться? Используя спецификацию W3 HTTP: «Со стороны клиента не поступало запроса в выделенном временном интервале, когда его ждал сервер. Клиент имеет возможность повторить запрос в любое время».

    409 Conflict (Конфликт)
    Код 409 является индикатором ситуации, когда запрос не выполняется в связи с противоречивостью обращения к веб-документу.
    Когда он применятся? Пользователь может получить такой код в случае загрузке файла на веб-сервер, где расположена более поздняя версия этого файла, что приводит к конфликту между версиями в системе управления.

    410 Gone (Исчез)
    Сервер дает подобный ответ, если раньше ресурс находился по определенному URL-адресу, но его удалили и на данный момент он недоступен. Пользователю не следует несколько раз повторять одно и то же самое обращение.

    Когда применяется такой статус-код? В ситуации, когда уже не представляется возможным получить доступ к ресурсу посредством этого запроса, а на сервере не содержатся данные о гипотетическом местонахождении ресурса. Если сервер подозревает, что веб-документ могут восстановить в ближайшие сроки, то клиенту лучше передать код 404.

    411 Length Required (Требуется длина)
    Запрос не указывает длину контента, и запрашивался в совершенной форме.
    Когда этот код показывается? Когда браузер не определяет длину запрашиваемого содержимого в заголовке запроса. Сервер не будет принимать запрос без валидного поля заголовка контента.

    412 Precondition Failed (Сбой предварительного условия)
    Сервер не отвечает на одно из предварительных условий, которые отправитель указал в запросе. Иными словами, один или несколько заголовков запросов были возвращены с атрибутом false.

    Когда этот код может применяться? В случаях, когда заголовок запроса, который делает валидный запрос к ресурсу, сообщает, что это конкретное обращение не применимо к этому конкретному ресурсу.

    413 Request Entity Too Large (Объект запроса слишком большой)
    Код 413 отображается в случаях, когда сервер отказывается обрабатывать запрос, потому что тело запроса слишком велико.
    Когда этот код может применяться? При использовании метода POST с контентом, который больше по объему, чем сервер, способен обработать.

    414 Request-URL Too Long (URL запроса слишком длинный)
    Этот код отображается, когда сервер не может обработать запрос, потому что указанный URL слишком длинный.
    Когда этот код может применяться? Когда POST-запрос преобразуется в GET-запрос. POST-запрос поддерживает отправку неограниченного количества данных, объединяя их при обращении к серверу. Однако, если запрос должен быть преобразован в GET-формат, он позволит привязать данные формы к URL-адресу, что даст возможность хранить информацию в больших размерах, чем она была доступна.

    415 Unsupported Media-Type (Неподдерживаемый тип)
    Код 415 отправляется, для указания, что сервер заметил часть запроса, которая была сделана в неподдерживаемом формате.
    Когда отображается такой код? Когда в запросе не указываются какие-либо типы носителей, поддерживаемые ресурсом или сервером. Например, пользователь запрашивает изображение в расширении, которое не поддерживается веб-сервером. Сервер знает, что запрашивалось, но не понимает формат, в котором хотели получить ресурс.

    416 Requested Range Not Satisfiable (Диапазон не подходит)
    Этот ответ пользователь получает, когда он запрашивает часть ресурса, но в то же время этот фрагмент не может быть предоставлен.
    Когда такой статус может применяться? Когда сервер запрашивает байты XXX-YYY ресурса, но ресурс немного меньше, чем указано при обращении.

    417 Expectation Failed (Ошибка ожидания)
    Такой статусный ответ получают, когда по какой-то причине сервер не удовлетворяет значение поля Expect заголовка запроса.
    Когда этот код может применяться? Все абсолютно прозрачно. Когда один из заголовков запросов, заголовок «Expect», получает обращение, на которое сервер не в состоянии ответить.

    418 I’m a teapot (Я чайник)
    Этот код был создан в 1998 году как одна из традиционных шуток на первое апреля IETF, в RFC 2324, как Hyper Text Coffee Pot Control Protocol и вряд ли он когда-нибудь будет обрабатываться современными HTTP-серверами.

    Может ли он использоваться? Конечно нет, все это было -15 лет назад и делалось ради смеха.


    422 Unprocessable Entity (Необрабатываемый объект)
    Сервер принял запрос и понял его суть, но не может выполнить обращение из-за содержания в нем некоторых семантических ошибок.
    Когда используется этот статус-код? Когда на стороне сервера прошло успешное принятие обращения, и сервер способен работать с указанным форматом данных; в теле запроса XML-документ содержит правильные синтаксические конструкции, но также в нем содержится какая-либо логическая ошибка, в связи с которой не представляется возможным управлять ресурсом.

    423 Locked (Заблокирован)
    Целевой ресурс, указанный в запросе, блокируется в связи с применением к нему определенного метода. Чтобы сделать ресурс доступным, следует разблокировать его или предоставить корректные данные авторизации.
    Когда этот код может применяться? Когда ресурс является закрытым, в основном это делается в целях обеспечения безопасности.

    424 Failed Dependency (Неудачная зависимость)
    424 код сообщает, что выполнение текущего запроса напрямую зависит от успешности другой операции, и если она не будет правильно завершена, то вся обработка запроса остановится.

    425 Unordered Collection (Неупорядоченная коллекция)
    Код 425 показывается пользователю, когда ресурс определяется одним из черновиков расширенного протокола коллекций WebDAV (Advanced Collections Protocol), но отсутствует в Advanced Collections Protocol и Versioning Ordered Collections Protocol.

    426 Upgrade Required (Нужно обновление)
    Этот код показывается, когда сервер дает клиенту инструкции по обновлению протокола (переключения на другой или новый протокол) Когда используется код? Обычно, когда в браузере используются устаревшие протоколы.

    428 Precondition Required (Требуется предпосылка)
    Исходный сервер требует указать предварительные условия при обращении. Этот код разработан во избежание конфликтных версий ресурса в тех ситуациях, когда клиент получает (GET) состояние ресурса, изменяет и отправляет (PUT) его обратно на сервер, и в то же время какая-то третья сторона также изменяет местоположение прямо на севере, что приводит к конфликту.

    Когда этот код может применяться? По запросу индикации условий, сервер как бы дает гарантии клиентам, что они используют правильную текущую копию ресурса. Если это не совсем так, то пользователь получает ошибку 428.

    429 Too Many Requests (Слишком много запросов)
    Этот ответ отправляется, если со стороны клиента поступало слишком большое количество обращений за короткий промежуток времени.
    Когда используется этот код? Когда пользователь отправляет слишком много обращений за краткосрочный период.

    431 Request Header Fields Too Large (Поля заголовков слишком большие)
    Появляется, когда сервер не намерен совершать обработку запроса, поскольку какое-нибудь из полей заголовка (или все существующие поля) слишком велики.
    Когда он применяется? Базово, когда заголовок запроса, поступающий от юзера больше, чем способен обработать сервер. Обращение можно повторить после того, как поля заголовка в нем будут сокращены.

    444 No Response (Нет ответа)
    Используется в лог-файлах сервера Nginx, для указания, что сервер не передавал информацию обратно пользователю и закрыл соединение.
    Какова сфера применения кода? В основном он использовался как инструмент защиты от вредоносного софта.

    449 Retry With (Microsoft) (Повторить попытку)
    Расширение Microsoft, которое указывает, что запрос следует повторить после завершения соответствующего действия.
    Когда этот код может применяться? Он часто создается, когда настройки запроса не соответствуют тому, что способен проверить сервер.

    450 Blocked by Windows Parental Controls – Microsoft (Заблокировано родительским контролем Windows)
    Расширение Microsoft. Эта ошибка возникает, когда в параметрах родительского контроля Windows установлена блокировка доступа к некоторым веб-документам.
    Когда применяется 450 код? В случае, если родители (зная об этой функции) прибегают к использованию родительского контроля, а id-access запросил доступ к заблокированному ресурсу.

    451 Unavailable For Legal Reasons (Недоступен по юридическим причинам)
    Новый HTTP-код статуса для ресурсов, которые заблокированы по юридическим соображениям. Применяется, чтобы указать, что доступ к нужному веб-ресурсу заблокировали по юридическим мотивам: например, посредством цензуры или правительства.

    5xx Ошибка сервера

    Коды 5xx выделены для случаев неудачной работы на стороне сервера.
    Эти ответы сервера часто отображаются, когда запросы пользователя не могут быть обработаны сервером по той или иной причине. Сервер должен иметь специальное сообщение для браузера, которое должно отображаться пользователю – оно уведомляет, что сервер (по какому-либо поводу) не в состоянии произвести обработку запроса.

    500 Internal Server Error (Внутренняя ошибка сервера)
    Этот статус сообщает о внутренней ошибке сервера, которая не совпадает с другими ошибками того же класса.
    Этот код используется, если ресурс или ссылка создается на сервере (например, календарь в системе резервирования), который технически не существует как ссылка или доступный ресурс, но пользователь видите их как ссылки.

    501 Not Implemented (Не поддерживается)
    Сервер либо не понимает метод запроса, либо не поддерживает инструкции, нужные, чтобы обработать обращение.
    Вы можете столкнуться с указанным кодом 501, когда сервер не имеет поддержки стандартных протоколов запросов, среди которых GET, OPTIONS, HEAD, POST и т. д.

    502 Bad Gateway (Плохой шлюз)
    Пользователь увидит 502 код, если сервер, работает в качестве шлюза или прокси-сервера, и он получил недопустимый ответ от сервера верхнего уровня.
    Когда используется подобный код? Обычно, когда сервер высшего уровня и прокси / шлюз не согласованы с протоколами, которые представленными в обращении. Как результат появляется ошибка обмена данных.

    503 Server Unavailable (Сервер недоступен)
    Код 503 означает, что возникли технические причины, из-за которых сервер на определенное время не способен обработать набор данных.
    Его допустимо использовать в случаях, когда на сайт есть повышенный спрос, но у сервера нет возможности обрабатывать все входящие запросы.

    504 Gateway Timeout (Тайм-аут шлюза)
    Сервер как шлюз или прокси-сервер не дождался ответа от вышестоящего сервера, чтобы завершить текущий запрос.
    Когда этот код может применяться? Когда прокси или шлюз используют как канал передачи данных, а два сервера при этом ожидают на ответ.

    505 HTTP Version Not Supported (Версия HTTP не поддерживается)
    Сервер не поддерживает версию HTTP протокола, обозначенную при обращении к нему.
    Где используется такой код? В тех случаях, которые были указаны выше! Если HTTP протокол более старый, чем нужно серверу, и, как следствие, он не поддерживается.

    506 Variant Also Negotiates (Вариант также перенаправляется)
    Такой ответ сервера последует, если при оформлении ошибочной конфигурации выбранный параметр указывает сам на себя, что приводит к прерыванию процесса связи.
    Когда он применяется? Когда сервер настроен неправильно и не может обработать запрос.

    507 Insufficient Storage (Недостаточно места)
    Ошибка 507 имеет место, когда сервер не может разместить данные, поскольку для текущего запроса недостаточно пространства.
    Этот код может быть применен, когда сервер загружен в полном объеме, а пользователь запрашивает ресурс, который уже имеется в наличии. Трудность здесь заключается в том, что на сервере нет места для хранения отправленных в запросе данных, чтобы отправить запрашиваемый ресурс.

    509 Bandwidth Limit Exceeded (Превышена пропускная способность)
    Этот код ответа используется, когда веб-сайт лимитирует ограничение трафика, предназначенное для него.
    Когда используется этот статус? Когда Apache запускает правильное расширение, а ISP имеет пропускную способность, которая может быть скоро превышена. Здесь имеется несколько форм ограничения.

    510 Not Extended (Нет расширения)
    Код 510 появляется, когда на сервере нет расширения, которое хочет использовать клиент. Когда этот код появляется? Когда сервер требует больше данных в запросе.

    511 Network Authentication Required (Требуется аутентификация сети)
    Этот статус-код демонстрируется, если клиенту следует сначала авторизоваться в сети, к примеру, необходимо ввести пароль для платного доступа в сеть Интернет.
    Когда используется этот код? Когда пользователь сначала должен дать свое согласие на условия использования, прежде чем он получит доступ к Интернету (например, к Wi-Fi точке доступа).

    ASP.NET, HTTP 404 и SEO

    Недавно, мой SEO оптимизатор сказал мне, что недоволен тем как ASP.NET возвращает HTTP ответ в случае ситуации 404, то есть страница не найдена. Я начал ковыряться и обнаружил пару интересных моментов, которые возможно кому-то пригодятся.

    1) Обычно, по умолчанию так сказать, мы ловим 404 такими настройками web.config

    Оданко, этот подход имет проблему, о которой мне и говорил СЕО оптимизатор. Давайте проведем небольшой тест и посмотрим какой HTTP код нам вернет ASP.NET в случае 404 ошибки.

    Итак, мы сначала получаем 302 (Redirect) и затем 200 то есть типа все хорошо. Но это на самом деле, как оказалось, плохо для SEO оптимизации.

    Проблема : Нам нужно чтобы ASP.NET возвращял HTTP 404 код в ситуации когда страница не найдена, а не просто редиректил на страницу ошибки с кодом 200.

    Решение 1

    Давайте немного поменяем наш web.config и сделаем чтобы редирект происходил не на статический html файл а на .aspx

    Теперь добавим в Page_Load этой 404.aspx страницы следующий код

    protected void Page_Load(object sender, EventArgs e)
    <
    Response.StatusCode = 404;
    >

    Теперь давайте протестируем

    Выглядит лучше, мы таки полчили 404 код на выходе, однако мой СЕО оптимизатор не доволен, так как мы все еще имеем как бы двойной ответ, то есть сначала 302 код редиректа а потом 404. Это, как мне сказали, плохо для Google поиска и нам нужно чтобы возвращался один ответ, с 404 кодом и больше ничего.

    VK API: HTTP response code sa >

    Переношу уже рабочего бота с хостинга на виртуальный сервер. На хостинге всё работает прекрасно, на серваке возвращается HTTP response code said error. Опытным путём выяснил, что ошибка происходит когда выполняется curl_init();

    То есть такой код работает:

    А уже последующее обращение к API ВК возвращает данную ошибку:

    Поэтому такой код не работает:

    На хостинге стоял Апач, на серваке — Nginx. Возможно, нужна какая-то особая конфигурация сервера?

    httpErrors ErrorMode = «Detailed» только для определенного кода ошибки

    У меня есть приложение MVC3 asp.net. В моем контроллере у меня есть действие Ajax, который устанавливает пользовательский код ответа с помощью Response.StatusCode = 600. Мне нужно пройти через ответ, как это без IIS пытается искать страницу ошибки. Я пытался использовать следующий код, чтобы IIS не использовать его пользовательскую страницу для статуса ответа 600.

    Проблема с выше фрагмент кода является то, что это относится ко всем кодам ответов, так что даже если код не удается с 500 Internal Server, реакция проходит как без вмешательства IIS. Это подвергает мой внутренний код контроллера и View для пользователя (если случайно некоторые происходит исключение, что я не обрабатывается).

    Итак, как настроить web.config пройти подробный ответ только тогда, когда response.statuscode 600 (пользовательский) и обеспечивают IIS по умолчанию пользовательские страницы на другие ошибки (например Внутренняя ошибка сервера 500).

    Если вы работаете в режиме интегрированного трубопровода можно попробовать установить TrySkipIisCustomErrors свойство верно:

    Это существо говорит HTTP specification четко определяет , что ответ HTTP код состояния не превосходит 5xx. Поэтому установка Response.StatusCode = 600; кажется, что — то очень необычное здесь. Что именно вы пытаетесь достичь и почему стандартные коды ответа HTTP , определенные в спецификации не может покрыть свой сценарий?

    В web.config я устанавливаю раздел ошибок пользовательского следующим образом:

    А затем в контроллерах, я до сих пор установить [HandleError] атрибут выше моего контроллера. Все необработанное исключение перейти к нормальной странице ошибки в разделяемых. Любые ошибки 404 перейти на страницу NotFound.

    Как я могу использовать HttpRequestMessage.CreateResponse () в ASP.NET 5

    У меня есть пустой проект веб-API, а также полный проект MVC, созданный с использованием VS2015. Я замечаю, что HttpRequestMessage находится в System.Net.Http , это нормально, но не для CreateResponse ниже:

    Этот код из моего промежуточного программного обеспечения журнала исключения, которое также возвращает отформатированный json из предыдущего веб-API 2.

    Я пытаюсь выяснить способ расширения CreateResponse , который предположительно доступен в System.Net.Http.HttpRequestMessageExtensions , а также класс HttpError . Оба ранее были в пакете Microsoft.AspNet.WebApi.Core .

    После просмотра кода ASP.NET 5, я считаю, что он доступен только в Microsoft.AspNet.Mvc.WebApiCompatShim . Однако он не включен в проект MVC-образца.

    Вопросы:

    Что такое WebApiCompatShim пакет и могу ли я безопасно его использовать в проекте?

    Каков правильный путь к CreateResponse из HttpRequestMessage ?

    Обновление

    Этот WebApiCompatShimWebSite показывает, что WebApiCompatShim есть

    чтобы получить Web API 2. * как поведение

    Так кажется просто для цели совместимости. Я должен перестроить код. Теперь я обнаруживаю, что у MVC нет функции обработчиков сообщений, и кажется, что обычное промежуточное ПО — это путь.

  • Илон Маск рекомендует:  Как разместить элементы списка горизонтально
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL