.axd генерируют ошибку 404

Ответ 1

Вам нужно создать тип MIME для этого расширения в IIS:

Чтобы определить тип MIME для определенного расширения, выполните следующие действия:

• Откройте консоль управления Microsoft IIS (MMC), щелкните правой кнопкой мыши имя локального компьютера и выберите "Свойства".
• Нажмите HTTP заголовки.
• Нажмите MIME-типы.
• Нажмите "Создать".
• В поле Расширение введите расширение имени файла, которое вы хотите (например,.axed)
• В поле MIME Type введите application/octet-stream.
• Применить новые настройки. Обратите внимание, что вы должны перезапустить службу публикации World Wide Web или дождаться перезагрузки рабочего процесса, чтобы изменения вступили в силу. В этом примере IIS теперь служит для файлов с расширением .axed.

Ответ 2

если вы используете IIS7, убедитесь, что вы добавили обработчик в раздел <system.webServer><handlers>:

<add name="MyName" path="MyName.axd" verb="*" type="NameSpace.Class, Assembly" />

Ответ 3

В моем случае я передавал проект из .NET 2.0 с использованием автоматического преобразования. Конвертер добавил раздел <system.webServer> и все обработчики и модули, которые находятся в <system.web>. Однако для каждого обработчика он добавил следующий атрибут: preCondition = "integMode, runtimeVersionv2.0" После удаления атрибута 404s остановился, и обработчик начал работать.

Ответ 4

Подтвердите, что в Request Filtering вы либо  * иметь .axd как разрешенное расширение, или  * have Allow unlisted file name extensions отмечен в настройках фильтрации запросов на запрос

Тот же эффект может быть достигнут в следующем разделе web.config:

<system.webServer>
    <security>
        <requestFiltering>
            <fileExtensions>
                <add fileExtension=".axd" allowed="true" />
            </fileExtensions>
        </requestFiltering>
    </security>
</system.webServer>

Ответ 5

У нас была ошибка 500 (это не 404, но кто знает) на нашем производственном сервере некоторое время назад. Ресурсам script удалось загрузить.

Проблема заключалась в разнице во времени между нашими серверами разработки и производства. Было -7 часов..NET бросил исключение из-за того, что попытался использовать "время в будущем" сборки со встроенными ресурсами script.

Уменьшение папки {website}/bin/ (на самом деле сборки в ней), созданное с каждым днем, решило проблему.

Ответ 6

Вы можете проверить следующее:

• Проверьте консоль управления IIS, что разрешено расширение .axd(расширение HTTP-обработчика по умолчанию).
• Также проверьте, установлен ли флажок "Проверить ли файл", не отмечен. Этот экран появляется после нажатия кнопки "Редактировать" после выбора расширения axd.
• Проверьте, правильно ли зарегистрирован обработчик HTTP в web.config. Он также должен быть в правильном разделе конфигурации в зависимости от версии IIS. Для классического режима IIS6 и IIS7 он должен быть в <system.web><httpHandlers>. Для интегрированного режима IIS7 он должен быть зарегистрирован в <system.webServer><handlers>.

Ответ 7

Можете ли вы сделать "плохой" запрос, который терпит неудачу, а затем проверить журналы системных журналов сервера и приложений?

Есть несколько вопросов вокруг axd, которые могут вызвать 404s или 500s (например, проблема времени в будущем, упомянутая Алексом), но оставляют след в журнале событий.

Посмотрите и разместите записи в журнале, в которых упоминаются axds.

Ответ 8

Я добавил атрибут runAllManagedModulesForAllRequests = "true" в модули.. node раздела system.webServer, 404s остановился и обработчик начал работать.

Ответ 9

Если это поможет кому-либо, у меня была такая же проблема, немногие из нас провели 2 дня. На 3 серверах все работало нормально, а также при разработке, но на этом сервере 404 не остановился. Решение, я изменил poold от интегрированного к классическому и который работал