Как найти request code

I am very new to Android Kotlin programming. I am making an app to create, read and delete file using Storage Access Framework. I did it by implementing deprecated startActivityForResult intent to perform file read, create, delete tasks. I tried to implement it using Activity Result API but I got stuck in request code which I could not find it.
In new implementation, there is resultCode but no requestCode.

My implemetation is below. How I can I implement the following using Activity Result API ?

How can I get request code from Activity Result API ?

fun createFile()
{
    val filename: String = etFileName.text.toString()
    val intent = Intent(Intent.ACTION_CREATE_DOCUMENT).apply {
        type = "text/*"
        addCategory(Intent.CATEGORY_OPENABLE)
        putExtra(Intent.EXTRA_TITLE, filename)
    }
    startActivityForResult(intent, WRITE_REQUEST_CODE)
}


fun readFile(){
    etFileName.setText("")
    val intent = Intent(Intent.ACTION_OPEN_DOCUMENT).apply {
        addCategory(Intent.CATEGORY_OPENABLE)
        type = "text/*"
    }
    startActivityForResult(intent, READ_REQUEST_CODE)
}

fun deleteFile(uri: Uri){
    val filename = queryName(contentResolver, uri)
    DocumentsContract.deleteDocument(contentResolver, uri)
    Toast.makeText(applicationContext, "Done deleting $filename", Toast.LENGTH_SHORT).show()
}

fun writeText(uri: Uri) : String{
    //var writetext: String = "typing high speed"
    var writeStream = contentResolver.openFileDescriptor(uri, "w")
    val filename: String = queryName(contentResolver, uri)
    etFileName.setText(filename)
    var fileOutputStream = FileOutputStream(writeStream?.fileDescriptor)
    fileOutputStream.write(filename.toByteArray())
    fileOutputStream.close()
    return filename.toString()
}

fun openFileContent(uri: Uri): String{
    val inputStream = contentResolver.openInputStream(uri)
    val reader = BufferedReader(InputStreamReader(inputStream))
    val stringBuilder = StringBuilder()

    val filename = queryName(contentResolver, uri)
    etFileName.setText(filename)
    var currentline = reader.readLine()

    while (currentline != null) {
        stringBuilder.append(currentline + "n")
        currentline = reader.readLine()
    }
    inputStream?.close()
    val str =  stringBuilder.toString()
    Log.d("Uri Read", ": $str")
    return str
}

private fun queryName(resolver: ContentResolver, uri: Uri): String {
    val returnCursor: Cursor = resolver.query(uri, null, null, null, null)!!
    val nameIndex: Int = returnCursor.getColumnIndex(OpenableColumns.DISPLAY_NAME)
    returnCursor.moveToFirst()
    val name: String = returnCursor.getString(nameIndex)
    returnCursor.close()
    return name
}

override fun onActivityResult(requestCode: Int, resultCode: Int, resultData: Intent?) {
    super.onActivityResult(requestCode, resultCode, resultData)

    if (requestCode == READ_REQUEST_CODE && resultCode == Activity.RESULT_OK) {
        val uri =resultData?.data
        Log.d("Uri Read", "$uri")
        if (uri != null) {
            val readfile: String = openFileContent(uri)
            etContent.setText(readfile)
        }
    } else if (requestCode == WRITE_REQUEST_CODE && resultCode == Activity.RESULT_OK) {
        resultData?.data?.also { uri ->
            Log.i("Uri Write", "Uri: $uri")   // 1
            val write = writeText(uri)   // 2
            etContent.setText(write)
        }
    } else if (requestCode == DELETE_REQUEST_CODE && resultCode == Activity.RESULT_OK) {
        val uri =resultData?.data
        Log.d("Uri Delete", "$uri")
        if (uri != null) {
            deleteFile(uri)
        }
    }
}

Since the above method is deprecated, I tried to implement it using Intent launcher, but there is no reference to requestCode anywhere so I am stuck here. It is as shown below :

val startforFile: ActivityResultLauncher<Intent> = registerForActivityResult(ActivityResultContracts.StartActivityForResult()){
    result: ActivityResult ->

    // could not find reference to requestCode here

    if (requestCode == READ_REQUEST_CODE && resultCode == Activity.RESULT_OK) {
        val uri =resultData?.data
        Log.d("Uri Read", "$uri")
        if (uri != null) {
            val readfile: String = openFileContent(uri)
            etContent.setText(readfile)
        }
    } else if (requestCode == WRITE_REQUEST_CODE && resultCode == Activity.RESULT_OK) {
        resultData?.data?.also { uri ->
            Log.i("Uri Write", "Uri: $uri")   // 1
            val write = writeText(uri)   // 2
            etContent.setText(write)
        }
    } else if (requestCode == DELETE_REQUEST_CODE && resultCode == Activity.RESULT_OK) {
        val uri =resultData?.data
        Log.d("Uri Delete", "$uri")
        if (uri != null) {
            deleteFile(uri)
        }
    }
}

Can anyone show me how it is done correctly ?

Библиотека requests является стандартным инструментом для составления HTTP-запросов в Python. Простой и аккуратный API значительно облегчает трудоемкий процесс создания запросов. Таким образом, можно сосредоточиться на взаимодействии со службами и использовании данных в приложении.

Содержание статьи

• Python установка библиотеки requests
• Python библиотека Requests метод GET
• Объект Response получение ответа на запрос в Python
• HTTP коды состояний
• Получить содержимое страницы в Requests
• HTTP заголовки в Requests
• Python Requests параметры запроса
• Настройка HTTP заголовка запроса (headers)
• Примеры HTTP методов в Requests
• Python Requests тело сообщения
• Python Requests анализ запроса
• Python Requests аутентификация HTTP AUTH
• Python Requests проверка SSL сертификата
• Python Requests производительность приложений
• Объект Session в Requests
• HTTPAdapter — Максимальное количество повторов запроса в Requests

В данной статье представлены наиболее полезные особенности requests. Показано, как изменить и приспособить requests к различным ситуациям, с которыми программисты сталкиваются чаще всего. Здесь также даются советы по эффективному использованию requests и предотвращению влияния сторонних служб, которые могут сильно замедлить работу используемого приложения. Мы использовали библиотек requests в уроке по парсингу html через библиотеку BeautifulSoup.

Ключевые аспекты инструкции:

• Создание запросов при помощи самых популярных HTTP методов;
• Редактирование заголовков запросов и данных при помощи строки запроса и содержимого сообщения;
• Анализ данных запросов и откликов;
• Создание авторизированных запросов;
• Настройка запросов для предотвращения сбоев и замедления работы приложения.

В статье собран оптимальный набор информации, необходимый для понимания данных примеров и особенностей их использования. Информация представлена в доступной в форме. Тем не менее, стоит иметь в виду, что для оптимального разбора инструкции потребуются хотя бы базовые знания HTTP.

Далее будут показаны наиболее эффективные методы использования requests в разрабатываемом приложении.

Python установка библиотеки requests

Для начала работы потребуется установить библиотеку requests. Для этого используется следующая команда.

Тем, кто для работы с пакетами Python, использует виртуальную среду Pipenv, необходимо использовать немного другую команду.

Сразу после установки requests можно полноценно использовать в приложении. Импорт requests производится следующим образом.

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

Python библиотека Requests метод GET

Такие HTTP методы, как GET и POST, определяют, какие действия будут выполнены при создании HTTP запроса. Помимо GET и POST для этой задачи могут быть использованы некоторые другие методы. Далее они также будут описаны в руководстве.

GET является одним из самых популярных HTTP методов. Метод GET указывает на то, что происходит попытка извлечь данные из определенного ресурса. Для того, чтобы выполнить запрос GET, используется requests.get().

Для проверки работы команды будет выполнен запрос GET в отношении Root REST API на GitHub. Для указанного ниже URL вызывается метод get().

Если никакие python ошибки не возникло, вас можно поздравить – первый запрос успешно выполнен. Далее будет рассмотрен ответ на данный запрос, который можно получить при помощи объекта Response.

Объект Response получение ответа на запрос в Python

Response представляет собой довольно мощный объект для анализа результатов запроса. В качестве примера будет использован предыдущий запрос, только на этот раз результат будет представлен в виде переменной. Таким образом, получится лучше изучить его атрибуты и особенности использования.

В данном примере при помощи get() захватывается определенное значение, что является частью объекта Response, и помещается в переменную под названием response. Теперь можно использовать переменную response для того, чтобы изучить данные, которые были получены в результате запроса GET.

HTTP коды состояний

Самыми первыми данными, которые будут получены через Response, будут коды состояния. Коды состояния сообщают о статусе запроса.

Например, статус 200 OK значит, что запрос успешно выполнен. А вот статус 404 NOT FOUND говорит о том, что запрашиваемый ресурс не был найден. Существует множество других статусных кодов, которые могут сообщить важную информацию, связанную с запросом.

Используя .status_code, можно увидеть код состояния, который возвращается с сервера.

.status_code вернул значение 200. Это значит, что запрос был выполнен успешно, а сервер ответил, отобразив запрашиваемую информацию.

В некоторых случаях необходимо использовать полученную информацию для написания программного кода.

В таком случае, если с сервера будет получен код состояния 200, тогда программа выведет значение Success!. Однако, если от сервера поступит код 404, тогда программа выведет значение Not Found.
requests может значительно упростить весь процесс. Если использовать Response в условных конструкциях, то при получении кода состояния в промежутке от 200 до 400, будет выведено значение True. В противном случае отобразится значение False.

Последний пример можно упростить при помощи использования оператора if.

Стоит иметь в виду, что данный способ не проверяет, имеет ли статусный код точное значение 200. Причина заключается в том, что другие коды в промежутке от 200 до 400, например, 204 NO CONTENT и 304 NOT MODIFIED, также считаются успешными в случае, если они могут предоставить действительный ответ.

К примеру, код состояния 204 говорит о том, что ответ успешно получен, однако в полученном объекте нет содержимого. Можно сказать, что для оптимально эффективного использования способа необходимо убедиться, что начальный запрос был успешно выполнен. Требуется изучить код состояния и в случае необходимости произвести необходимые поправки, которые будут зависеть от значения полученного кода.

Допустим, если при использовании оператора if вы не хотите проверять код состояния, можно расширить диапазон исключений для неудачных результатов запроса. Это можно сделать при помощи использования .raise_for_status().

В случае вызова исключений через .raise_for_status() к некоторым кодам состояния применяется HTTPError. Когда код состояния показывает, что запрос успешно выполнен, программа продолжает работу без применения политики исключений.

На заметку. Для более продуктивной работы в Python 3.6 будет не лишним изучить f-строки. Не стоит пренебрегать ими, так как это отличный способ упростить форматирование строк.

Анализ способов использования кодов состояния, полученных с сервера, является неплохим стартом для изучения requests. Тем не менее, при создании запроса GET, значение кода состояния является не самой важной информацией, которую хочет получить программист. Обычно запрос производится для извлечения более содержательной информации. В дальнейшем будет показано, как добраться до актуальных данных, которые сервер высылает отправителю в ответ на запрос.

Зачастую ответ на запрос GET содержит весьма ценную информацию. Она находится в теле сообщения и называется пейлоад (payload). Используя атрибуты и методы библиотеки Response, можно получить пейлоад в различных форматах.

Для того, чтобы получить содержимое запроса в байтах, необходимо использовать .content.

Использование .content обеспечивает доступ к чистым байтам ответного пейлоада, то есть к любым данным в теле запроса. Однако, зачастую требуется конвертировать полученную информацию в строку в кодировке UTF-8. response делает это при помощи .text.

Декодирование байтов в строку требует наличия определенной модели кодировки. По умолчанию requests попытается узнать текущую кодировку, ориентируясь по заголовкам HTTP. Указать необходимую кодировку можно при помощи добавления .encoding перед .text.

Если присмотреться к ответу, можно заметить, что его содержимое является сериализированным JSON контентом. Воспользовавшись словарем, можно взять полученные из .text строки str и провести с ними обратную сериализацию при помощи использования json.loads(). Есть и более простой способ, который требует применения .json().

Тип полученного значения из .json(), является словарем. Это значит, что доступ к его содержимому можно получить по ключу.

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

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

.headers возвращает словарь, что позволяет получить доступ к значению заголовка HTTP по ключу. Например, для просмотра типа содержимого ответного пейлоада, требуется использовать Content-Type.

У объектов словарей в качестве заголовков есть своим особенности. Специфика HTTP предполагает, что заголовки не чувствительны к регистру. Это значит, что при получении доступа к заголовкам можно не беспокоится о том, использованы строчным или прописные буквы.

При использовании ключей 'content-type' и 'Content-Type' результат будет получен один и тот же.

Это была основная информация, требуемая для работы с Response. Были задействованы главные атрибуты и методы, а также представлены примеры их использования. В дальнейшем будет показано, как изменится ответ после настройки запроса GET.

Python Requests параметры запроса

Наиболее простым способом настроить запрос GET является передача значений через параметры строки запроса в URL. При использовании метода get(), данные передаются в params. Например, для того, чтобы посмотреть на библиотеку requests можно использовать Search API на GitHub.

Передавая словарь {'q': 'requests+language:python'} в параметр params, который является частью .get(), можно изменить ответ, что был получен при использовании Search API.

Можно передать параметры в get() в форме словаря, как было показано выше. Также можно использовать список кортежей.

Также можно передать значение в байтах.

Строки запроса полезны для уточнения параметров в запросах GET. Также можно настроить запросы при помощи добавления или изменения заголовков отправленных сообщений.

Для изменения HTTP заголовка требуется передать словарь данного HTTP заголовка в get() при помощи использования параметра headers. Например, можно изменить предыдущий поисковой запрос, подсветив совпадения в результате. Для этого в заголовке Accept медиа тип уточняется при помощи text-match.

Заголовок Accept сообщает серверу о типах контента, который можно использовать в рассматриваемом приложении. Здесь подразумевается, что все совпадения будут подсвечены, для чего в заголовке используется значение application/vnd.github.v3.text-match+json. Это уникальный заголовок Accept для GitHub. В данном случае содержимое представлено в специальном JSON формате.

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

Примеры HTTP методов в Requests

Помимо GET, большой популярностью пользуются такие методы, как POST, PUT, DELETE, HEAD, PATCH и OPTIONS. Для каждого из этих методов существует своя сигнатура, которая очень похожа на метод get().

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

При использовании каждого из данных методов в Response могут быть возвращены заголовки, тело запроса, коды состояния и многие другие аспекты. Методы POST, PUT и PATCH в дальнейшем будут описаны более подробно.

Python Requests тело сообщения

В соответствии со спецификацией HTTP запросы POST, PUT и PATCH передают информацию через тело сообщения, а не через параметры строки запроса. Используя requests, можно передать данные в параметр data.

В свою очередь data использует словарь, список кортежей, байтов или объект файла. Это особенно важно, так как может возникнуть необходимость адаптации отправляемых с запросом данных в соответствии с определенными параметрами сервера.

К примеру, если тип содержимого запроса application/x-www-form-urlencoded, можно отправить данные формы в виде словаря.

Ту же самую информацию также можно отправить в виде списка кортежей.

В том случае, если требуется отравить данные JSON, можно использовать параметр json. При передачи данных JSON через json, requests произведет сериализацию данных и добавит правильный Content-Type заголовок.

Стоит взять на заметку сайт httpbin.org. Это чрезвычайно полезный ресурс, созданный человеком, который внедрил использование requests – Кеннетом Рейтцом. Данный сервис предназначен для тестовых запросов. Здесь можно составить пробный запрос и получить ответ с требуемой информацией. В качестве примера рассмотрим базовый запрос с использованием POST.

Здесь видно, что сервер получил данные и HTTP заголовки, отправленные вместе с запросом. requests также предоставляет информацию в форме PreparedRequest.

Python Requests анализ запроса

При составлении запроса стоит иметь в виду, что перед его фактической отправкой на целевой сервер библиотека requests выполняет определенную подготовку. Подготовка запроса включает в себя такие вещи, как проверка заголовков и сериализация содержимого JSON.

Если открыть .request, можно просмотреть PreparedRequest.

Проверка PreparedRequest открывает доступ ко всей информации о выполняемом запросе. Это может быть пейлоад, URL, заголовки, аутентификация и многое другое.

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

Python Requests аутентификация HTTP AUTH

Аутентификация помогает сервису понять, кто вы. Как правило, вы предоставляете свои учетные данные на сервер, передавая данные через заголовок Authorization или пользовательский заголовок, определенной службы. Все функции запроса, которые вы видели до этого момента, предоставляют параметр с именем auth, который позволяет вам передавать свои учетные данные.

Одним из примеров API, который требует аутентификации, является Authenticated User API на GitHub. Это конечная точка веб-сервиса, которая предоставляет информацию о профиле аутентифицированного пользователя. Чтобы отправить запрос API-интерфейсу аутентифицированного пользователя, вы можете передать свое имя пользователя и пароль на GitHub через кортеж в get().

Запрос выполнен успешно, если учетные данные, которые вы передали в кортеже auth, действительны. Если вы попытаетесь сделать этот запрос без учетных данных, вы увидите, что код состояния 401 Unauthorized.

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

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

Хотя вам не нужно явно указывать обычную аутентификацию, может потребоваться аутентификация с использованием другого метода. requests предоставляет другие методы аутентификации, например, HTTPDigestAuth и HTTPProxyAuth.

Вы даже можете предоставить свой собственный механизм аутентификации. Для этого необходимо сначала создать подкласс AuthBase. Затем происходит имплементация __call__().

Здесь пользовательский механизм TokenAuth получает специальный токен. Затем этот токен включается заголовок X-TokenAuth запроса.

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

Пока вы думаете о безопасности, давайте рассмотрим использование requests в SSL сертификатах.

Python Requests проверка SSL сертификата

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

Хорошей новостью является то, что requests по умолчанию все делает сам. Однако в некоторых случаях необходимо внести определенные поправки.

Если требуется отключить проверку SSL-сертификата, параметру verify функции запроса можно присвоить значение False.

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

Примечание. Для предоставления сертификатов requests использует пакет, который вызывается certifi. Это дает понять requests, каким ответам можно доверять. Поэтому вам следует часто обновлять certifi, чтобы обеспечить максимальную безопасность ваших соединений.

Python Requests производительность приложений

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

Таймауты

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

По умолчанию в requests на ответ время не ограничено, и весь процесс может занять значительный промежуток. По этой причине вы всегда должны указывать время ожидания, чтобы такого не происходило. Чтобы установить время ожидания запроса, используйте параметр timeout. timeout может быть целым числом или числом с плавающей точкой, представляющим количество секунд ожидания ответа до истечения времени ожидания.

В первом примере запрос истекает через 1 секунду. Во втором примере запрос истекает через 3,05 секунды.

Вы также можете передать кортеж. Это – таймаут соединения (время, за которое клиент может установить соединение с сервером), а второй – таймаут чтения (время ожидания ответа, как только ваш клиент установил соединение):

Если запрос устанавливает соединение в течение 2 секунд и получает данные в течение 5 секунд после установления соединения, то ответ будет возвращен, как это было раньше. Если время ожидания истекло, функция вызовет исключение Timeout.

Ваша программа может поймать исключение Timeout и ответить соответственно.

Объект Session в Requests

До сих пор вы имели дело с requests API высокого уровня, такими как get() и post(). Эти функции являются абстракцией того, что происходит, когда вы делаете свои запросы. Они скрывают детали реализации, такие как управление соединениями, так что вам не нужно о них беспокоиться.

Под этими абстракциями находится класс под названием Session. Если вам необходимо настроить контроль над выполнением запросов или повысить производительность ваших запросов, вам может потребоваться использовать Session напрямую.

Сессии используются для сохранения параметров в запросах.

Например, если вы хотите использовать одну и ту же аутентификацию для нескольких запросов, вы можете использовать сеанс:

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

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

HTTPAdapter — Максимальное количество повторов запроса в Requests

В случае сбоя запроса возникает необходимость сделать повторный запрос. Однако requests не будет делать это самостоятельно. Для применения функции повторного запроса требуется реализовать собственный транспортный адаптер.

Транспортные адаптеры позволяют определить набор конфигураций для каждой службы, с которой вы взаимодействуете. Предположим, вы хотите, чтобы все запросы к https://api.github.com были повторены три раза, прежде чем, наконец, появится ConnectionError. Для этого нужно построить транспортный адаптер, установить его параметр max_retries и подключить его к существующему объекту Session.

При установке HTTPAdapter, github_adapter к session, session будет придерживаться своей конфигурации для каждого запроса к https://api.github.com.

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

Заключение

Изучение библиотеки Python requests является очень трудоемким процессом.

После разбора данных в статье примеров можно научиться тому, как:

• Создавать запросы, используя различные методы HTTP – GET, POST и PUT;
• Настраивать свои запросы, изменив заголовки, аутентификацию, строки запросов и тела сообщений;
• Проверять данные, которые были отправлены на сервер, а также те данные, которые сервер отправил обратно;
• Работать с проверкой SSL сертификата;
• Эффективно использовать requests, max_retries, timeout, Sessions и транспортные адаптеры.

Грамотное использование requests позволит наиболее эффективно настроить разрабатываемые приложения, исследуя широкий спектр веб-сервисов и данных, опубликованных на них.

• Данная статья является переводом статьи: Python’s Requests Library (Guide)
• Изображение статьи принадлежит сайту © RealPython

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

Что такое код сервера

Код сервера (его еще называют кодом состояния HTTP) — последовательность из трех чисел с небольшим текстовым пояснением, который запрашивают и проверяют браузеры и поисковые роботы. Вот пример как это выглядит:

Страница с кодом ответа сервера Discord при переходе на несуществующую страницу

В этом случае код — число 404. Оно означает, что запрашиваемая страница не существует. Под числом небольшое текстовое сообщение: «вы выглядите потерянным, вот вам несколько других страниц». Под сообщением — альтернатива: ссылки на существующие страницы.

Читайте также: 11 способов проверки битых ссылок на сайте

Какие бывают коды ответов

Классы состояния — это группы кодов, которые объединяются общими признаками. Всего есть пять классов: принадлежность определяется первой цифрой из трех.

Класс 1. Выглядит так: 1ХХ. Это временные информационные коды. Они сообщают о том, что запрос принят и находится в обработке.

Класс 2. Выглядит так: 2ХХ. Сообщает об успешной обработке запроса.

Класс 3. Выглядит так: 3ХХ. Сообщает о перенаправлении с одного адреса на другой. Эти коды говорят об изменении URL. Используются при создании зеркал или переносе сайта на новый движок.

Класс 4. Выглядит так: 4ХХ. Говорит об ошибке со стороны посетителя. Обычно после числа идет небольшой текст с объяснением — в чем проблема. Такие коды говорят о запрете просмотра страницы или об ее отсутствии.

Класс 5. Выглядит так: 5ХХ. Сообщает об ошибке со стороны сервера. После этого класса тоже следует текстовое сообщение с объяснением причины поломки. 

Теперь разберем более распространенные виды ответов в каждом классе.

Класс 1

100 Continue. Промежуточный ответ сервера. Говорит о том, что сервер принял запрос и начинает обработку.

101 Switching Protocols. Код ответа указывает протокол, который переключает сервер, используя запрос Upgrade. В ответ сервер отправляет заголовок ответа Upgrade с указанием протокола, на который переключился.

102 Processing. Это значит, что сервер получил запрос и обрабатывает его. Клиент не должен разрывать соединение, чтобы дождаться ответа от сервера. Этот код используется в протоколе WebDAV (измененный HTTP для работы с файлами).

Класс 2

200 Ok. Говорит об успешной обработке запроса. Например, запрошенные страница или данные найдены и готовы к просмотру. Всем страницам, которые участвуют в индексировании, присваивается код 200.

202 Accepted. Запрос принят и будет обрабатываться долго. Пользователь может не дожидаться окончания запроса. Используется, когда запрос обрабатывается другим сервером. Такой код используется сервером, чтобы выполнять несколько запросов одновременно: пока пользователь с кодом 202 ждет окончания операции, 200 уже «видит» страницу.

203 Non-Authoritative Information. Код означает, что обработка запроса прошла успешно. Но информация поступила не от сервера, а от другого источника: облака, резервной копии.

204 No Content. Такой код используется на портал для запуска скриптов. Например, когда пользователь кликает по свободному месту на сайте.

205 Reset Content. Говорит о том, что браузеру нужно очистить форму, в которую вписаны данные. Такой код используется, чтобы очистить поля, заполненные при регистрации. При это обновлять ресурс не нужно.

Класс 3

300 Multiple Choices. Говорит о том, что указанный URL обозначает больше, чем один ресурс. Например, страницу, переведенную на несколько языков. 

301 Moved Permanently. Ответ означает, что запрошенный URL изменен или больше не существует, а пользователю предлагается перейти по новой ссылке. 

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

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

303 See Other. Указывает, что происходит перенаправление на другую страницу. Чтобы новая страница индексировалась, она должна отвечать на код 200. Такой код используется для страниц с подтверждением. Например, когда сайт высылает код подтверждения регистрации. 

304 Not Modified. Это значит, что предыдущая версия страницы не изменена. Благодаря этому робот индексирует ее без загрузки. Из-за этого сервер меньше нагружается и повышается время безотказной работы. А пользователь работает с версией страницы, которая сохранена в памяти браузера. 

У пользователей часто возникает ошибка HTTP 304. Такое бывает, если компьютер заражен вирусами или Windows медленно работает. Чтобы решить проблему, нужно проверить ПК на вирусы и очистить от лишних файлов. Еще можно восстановить записи в реестре системы. Но такую процедуру лучше доверить мастерам сервисного центра: если делать самостоятельно, можно превратить ПК в «кирпич».

305 Use Proxy. Сайт будет доступен только при использовании прокси-сервера. При этом нужно использовать сервер, который указан в разделе Location. Такой код предназначен для защиты сайта. 

308 Permanent Redirect. Полностью повторяет запрос 301. Разница в методе выполняемого запроса.

Класс 4

400 Bad Request. Сервер не может понять запрос, потому что он введен с ошибкой. Под ошибкой обычно понимается синтаксическая: некорректно введен URL. Также код 400 появляется, когда пользователь пытается загрузить на сайт слишком большой файл. Решить проблему помогает смена запроса или очистка cookies. Чтобы очистить куки в браузере, нужно перейти в настройки, в раздел конфиденциальности и безопасности.

401 Unauthorized. У клиента не получается зайти на страницу сайта, потому что у него не хватает прав доступа. Такая ошибка возникает на сайтах, где есть форма для авторизации. Решить ошибку можно двумя способами: войти в систему с использованием логина и пароля или очистить кэш браузера.

403 Forbidden. Этот код говорит о запрете на просмотр страницы. Такое бывает, если для IP-адреса внесен запрет на уровне сервера. Решить проблему можно с помощью VPN или прокси.

Что такое прокси? Как выбрать качественный прокси-сервер? Прокси для SEO, парсинга, арбитража и пр.

404 Not Found. Код означает, что запрашиваемая страница (сайт или документ) не существует или расположена по другому адресу. 

Ошибка 404 влияет на SEO-оптимизацию: если страница не существует / не доступна, поисковые роботы не будут ее индексировать и показывать в поиске. А еще переходы по битым ссылкам ухудшают поведенческие факторы. Но нивелировать негатив поможет грамотное оформление 404-страницы. Можно сделать ее с юмором, перенаправить трафик на другие ресурсы.

405 Method Not Allowed. Соответствующий код появляется, если на этапе обработки запроса сервер получает запрет. Такое случается, если нарушается работа php-скриптов. Ошибку можно решить с помощью перезагрузки страницы. Также помогает проверить все скрипты и удалить дополнения в CMS. 

408 Request Timeout. Это значит, что сервер прервал соединение. Такое бывает, когда сервер не получает запросов от посетителей долгое время. Если пользователь сам прекращает соединение, ошибки не возникает.

409 Conflict.Означает конфликт между пользовательским запросом и сервером. Например, клиент хочет скачать с сайта файл «фото01». Но раньше файл назывался «фото1» и это название сохранилось в кеше. Из-за этого сервер не понимает, что хочет скачать пользователь — возникает конфликт.

410 Gone. Это значит, что документ удален с сервера навсегда. Если поисковый робот получит этот код, он больше не будет просматривать страницу.

413 Request Entity Too Large. Ошибка возникает, если пользователь пытается загрузить слишком большой файл на сайт. Стандартно допустимый размер загружаемого файла — 1 Мб. Если клиент пытается загрузить больше — возникает ошибка. Чтобы решить проблему, нужно увеличить размер максимально загружаемого файла. Для этого нужно вносить изменения в настройки Nginx, php и apache. (Есть видео, как это делать в CMS WordPress.)

414 Request-URL Too Long. Если пользователь пытается сделать запрос с длинным URL, возникает такая ошибка.

423 Locked. Такая ошибка возникает, если IP-адрес блокируется хостером. Блокировку можно получить за сильную активность, интернет-мошенничество или вирусы. 

451 Unavailable For Legal Reasons. Новая ошибка, которая набирает популярность. Она появляется на сайтах, которые заблокированы государством. Ошибка 451 — дополнение к 403.

Класс 5

500 Internal Server Error. Ошибка из-за сбоев на сервере. Возникает при неправильной конфигурации файла .htaccess. Чтобы решить проблему, нужно изменить директиву Options: поставить в начале строки #.

502 Bad Gateway. Возникает, если есть промежуточный сервер. Случается, когда промежуточный сервер получает запрос и запрашивает данные у «главного» сервера, и получает неправильный ответ. В решении ошибки помогает очистка кеша браузера, обновление страницы и очистка DNS-кеша.

503 Service Unavailable. У сервера не получается обрабатывать запросы по техническим причинам. Например, если на сервере ведутся какие-то работы.

504 Gateway Timeout. Шлюз не дает ответа. Появляется, если ответ от главного сервера не получен.

507 Insufficient Storage. Ошибка высвечивается, если у сервера нет места работы с операцией. Проблему можно решить перезагрузкой. Или просто подождать.

511 Network Authentication Required. Значит, что нужно пройти авторизацию для доступа к интернету. Такой ответ высылает посредник, например, провайдер. Чтобы решить проблему, нужно написать в поддержку провайдера.

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

Как проверить код сервера

Начнем с ручного способа. Для этого перейдите на сайт через браузер Chrome и откройте консоль клавишей «F12». (Или «Fn + F12» на ноутбуках. Также инструменты разработчика можно включить сочетанием клавиш «Ctrl + Shift + I».) Теперь перейдите во вкладку «Network» и нажмите «Ctrl + R».

Ручная проверка кодов ответа страниц в консоли

Чтобы узнать код страницы, нужно смотреть столбец «Status».

Коды ответа сервера в столбце Status

Теперь о проверках с помощью сторонних сайтов и плагинов.

Bertal

Bertal — сервис для просмотра http-заголовков, веб-файлов (.html, .php, .asp, .gif, .jpg, .css и др.). Также позволяет просматривать html-код страниц. Работает с протоколами HTTP, HTTPS, FTP.

Возможности:

• Запрос информации методами HEAD, GET, POST. Метод HEAD — если запрашивается заголовок. GET — если запрашивается заголовок и тело. POST — как и GET, но с заполненной строкой POST.
• Поддерживаемые поисковые роботы: YandexBot, GoogleBot, BingBot, Yahoo, Baiduspider.
• Поддерживаемые браузеры: Mozilla Firefox, Google Chrome, Internet Explorer, Opera, Opera mini.
• Работает с Proxy.
• Можно указывать содержимое Cookies.

Отчет по странице от Bertal

Стоимость. Бесплатно.

PR-CY

PR-CY — cервис для SEO-аудита сайта, мониторинга и проверки позиций в поисковой выдачи. Подходит для анализа кодов ответа сервера, метатегов, содержимого страниц. Есть функции мониторинга сайта, проверки индексирования.

Возможности:

• Проверка кодов ответа страниц. Сервис проверяет все элементы: текст, скрипты, видео, фотографии. После PR-CY дает рекомендации: сжать текст, сократить HTML, CSS или JS.
• Работает с видами запросов: GET, POST, HEAD.
• Глубокий анализ: проверка редиректов, поиск всех кодов.
• Работает с поисковыми системами Google и Yandex.
• Проверка контента: пустые заголовки, лишние скрипты, нерабочие внешние ссылки.

Еще у PR-CY есть много чего: проверка скорости загрузки, вирусов, срока действия SSL-сертификата и др.

Результаты анализа сайта в PR-CY

Стоимость. Есть бесплатный тариф для экспресс-анализа сайта. Для полного аудита нужно покупать подписку. Она стартует от 990 ₽ в месяц. Позволяет вести до 5 проектов и проверять 1 000 страниц. Дорогие тарифы отличаются тем, что можно вести больше проектов и проверять больше страниц.

Читайте также: Как оптимизировать изображения для сайта

Checkmy

Checkmy — помогает проверить коды и заголовки ответа сервера. А еще доступность URL адресов, кеширование страниц, сжатие контента, исходный код, тип сервера и корректность переадресаций.

Возможности:

• Работает с доменам на кириллице.
• Работает через мобильную версию.
• Проверяет страницы с несколькими редиректами.
• Показывает размер и скорость загрузки страницы.
• Проверяет контент на сжатие.

Проверка кодов ответа сервера через Chekmy

Стоимость. Бесплатно.

Sitechecker

Sitechecker подходит для мониторинга сайта и полного аудита.  

Возможности:

• Проверка состояния страницы и кодов ответа.
• Подсчет «веса» HTML-кода страницы. Если он больше 2 Мб, сервис подскажет, как его уменьшить.
• Отдельная проверка страницы с кодом 404.
• Проверка индексации поисковыми системами.
• SEO-анализ страницы: проверка title, description, заголовков h1-h6. Проверка изображений и атрибутов Alt, внутренних и внешних ссылок.
• SEO-аудит сайта: оценка битых ссылок и редиректов, метатегов, скорости загрузки.
• Мониторинг ресурса: контроль статуса индексирования, защита от взломов и отслеживание сайтов конкурентов.

Аудит сайта не сервисе Sitecheker

Стоимость. Можно сделать проверку кодов бесплатно. Но функции мониторинга, проверки обратных ссылок и индексации будут недоступны. Платная подписка стартует от 29 $ в месяц. Для подписки доступно 3 тарифа. Они отличаются количеством сайтов, которые можно проверять.

А еще за парсингом метатегов и заголовков, анализом индексации страниц, съемом позиций в поисковиках, сбором семантического ядра можно обратиться в Promopult. Это мощная платформа для комплексного продвижения в интернете: поисковой оптимизации, контекстной и таргетированной рекламы, управления репутацией.

Яндекс.Вебмастер

Яндекс.Вебмастер поможет узнать, доступны ли страницы для поисковых роботов Яндекса. (Но ответ, полученный через Яндекс.Вебмастер, может отличаться от того, который получит поисковый робот. Дело в том, что инструмент работает через другой IP-адрес. Об этом сказано в Яндекс.Справке.)

Возможности:

• Проверка всех классов ответа сервера.
• Дополнительно можно узнать срок действия SSL-сертификата.
• Проверяет страницы размером до 10 Мб.
• Работает с файлами этих типов: PDF, DOC/DOCX, XLS/XLSX, PPT/PPTX, ODS, ODP, ODT, ODG, RTF, TXT и SWF.

Проверка ответа сервера через Яндекс.Вебмастер

Стоимость. Бесплатно.

Converseo

Converseo подходит для как для проверки одиночного URL, так и для массового отслеживания.

Возможности:

• Работа с методами GET, POST, HEAD.
• Есть дополнительные функции: сравнение списков, загрузка фото из Instagram.
• Готовый отчет можно скачать в формате CSV.

Вот так выглядит отчет по массовой проверке URL на сайте Converseo.

Вот так выглядит отчет по одиночной проверке URL на сайте Converseo.

Стоимость. Бесплатно.

Coolakov

Coolakov — работает также, как и Converseo. Есть и дополнительные функции.

Возможности:

• Массовая проверка URL. Особенность в том, что выдается конечный ответ сервера. Например, если был редирект на рабочую страницу — ответ будет 200. Если на сломанную — в зависимости от ошибки.
• Поддерживаемые браузеры: Mozilla Firefox, Google Chrome, Safari.
• Проверка доступности сайта.
• Измерение скорости загрузки портала.
• Проверка индекса качества сайта.
• Проверка орфографии.

Проверка ответов сервера через Coolakov

Стоимость. Бесплатно.

Headmasterseo

Headmasterseo. Программа для Windows и Mac, которая проверяет массовые URL. Отслеживает коды состояния, редиректы, время ответа и заголовки ответов.

Возможности:

• Проверка URL с помощью метода HEAD.
• Одновременная проверка 500 ссылок.
• Проверка циклов перенаправления. Есть тестер, который оценит, правильно ли настроен редирект.
• Работает с прокси.
• Готовый отчет можно экспортировать в формате CSV.
• Проверка полей заголовков.
• Проверка Sitemap файлов в формате XML.

Пример отчета в Headmasterseo

Стоимость. До 500 URL можно проверять бесплатно. Чтобы проверить больше, нужно платить. За 10 000 URL придется заплатить 50 $. За 100 000 — 100 $. Неограниченное количество ссылок можно проверять за 150 $.

Читайте также: Исчерпывающий гид по поисковым операторам Google и Яндекса

Плагины

Redirect Path Link. Это бесплатный плагин для Google Chrome. Он поможет провести SEO-аудит сайта и проверить HTTP-заголовки. Работает только с 3 классом кодов сервера. 

Robots Exclusion Checker. Помогает оптимизировать сайт, найти проблемы в индексации и сделать SEO-аудит. Плагин бесплатный. Работает со всеми классами кодов и поисковыми роботами Googlebot, Bing, Yahoo.

SEO META in 1 CLICK. Бесплатный плагин для Google Chrome. Помогает проверить коды ответа сервера, проанализировать заголовки H1-H6, проверить изображения и Alt атрибуты к ним и др. 

Website SEO Checker: Free Audit & Analysis. Бесплатный плагин от Sitecheker. В нем есть такие же функции, как и на сайте: аудит, мониторинг, анализ, просмотр кодов ответа и т.д.

Коротко о главном

Код ответа сервера — это трехзначное число с небольшим текстовым сопровождением. Коды делят на 5 классов:

1. 1ХХ — информационные.
2. 2ХХ — успешные.
3. 3ХХ — переадресация
4. 4ХХ — проблемы со стороны пользователя.
5. 5ХХ — проблемы со стороны сервера.

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

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

А чтобы глубже разобраться в SEO, приходите учиться в CyberMarketing. У нас есть статьи, вебинары, базовые и продвинутые курсы по поисковому продвижению. Преподают эксперты Promopult: Руслан Байбеков и Евгений Костин.