При выполнении запроса api v3 true api auth simplesignin возникла ошибка код состояния http 400

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

В этом материале поговорим об ошибке 400 Bad Request. Почему она появляется и как ее исправить. 

Чуть подробнее об ошибке 400

Как и другие коды, начинающиеся на четверку, 400 Bad Request говорит о том, что возникла проблема на стороне пользователя. Зачастую сервер отправляет ее, когда появившаяся неисправность не подходит больше ни под одну категорию ошибок. 

Стоит запомнить — код 400 напрямую связан с клиентом (браузером, к примеру) и намекает на то, что отправленный запрос со стороны пользователя приводит к сбою еще до того, как его обработает сервер (вернее, так считает сам сервер). 

Из-за чего всплывает Bad Request?

Есть 4 повода для возникновения ошибки сервера 400 Bad Request при попытке зайти на сайт:

1. Некорректно настроенные HTTP-заголовки в запросе со стороны клиента. Некоторые приложения и сайты мониторят заголовки на предмет наличия в них чего-нибудь подозрительного. Если ваш запрос не соответствует ожиданиям сервера, то высока вероятность появления ошибки 400 (но это не всегда вина пользователя).
2. Такой же сбой появляется, если клиент пытается загрузить на сервер файл слишком большого размера. Это происходит, потому что на большинстве сайтов есть ограничения по размеру загружаемых данных. Причем ограничение может быть как в 2 гигабайта, так и в 600 килобайт.
3. Еще ошибка 400 появляется, когда пользователь пытается получить доступ к несуществующей странице. То есть в браузер банально ввели ссылку с опечаткой, некорректным доменом или поддоменом.
4. Устаревшие или измененные куки-файлы. Сервер может воспринять подмену куки-файлов как попытку атаковать или воспользоваться дырой в безопасности. Поэтому такие запросы сходу блокируются.

Исправляем ошибку 400 Bad Request на стороне клиента

Так как ошибка 400 в 99 случаев из 100 возникает на стороне клиента, начнем с соответствующих методов. Проверим все элементы, участвующие в передаче запроса со стороны клиента (браузера).

Проверяем адрес сайта

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

А еще стоит поискать запрашиваемую страницу через поисковик, встроенный в сайт. Есть вероятность, что конкретная страница куда-то переехала, но сервер не может показать подходящий HTTP-код в духе 404 Not Found. Если, конечно, сам сайт работает. 

Сбрасываем параметры браузера

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

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

В зависимости от браузера процесс удаления куки-файлов может немного отличаться. В Chrome это работает так:

• Открываем настройки браузера. 
• Переходим в раздел «Конфиденциальность и безопасность».
• Выбираем «Файлы cookie и другие данные».
• Нажимаем на кнопку «Удалить все».

Для чистки cookies можно использовать стороннюю программу в духе CCleaner или CleanMyPC.

Загружаем файл подходящего размера

Если ошибка 400 Bad Request появляется при попытке загрузить на сайт какой-нибудь файл, то стоит попробовать загрузить файл поменьше. Иногда вебмастера ленятся грамотно настроить ресурс, и вместо понятного объяснения вроде «Загружаемые файлы не должны быть размером больше 2 мегабайт» люди получают Bad Request. Остается только гадать, какой там у них лимит. 

Устраняем проблемы, связанные с Windows и сторонним софтом

Помимо браузера, на работу сети могут влиять другие программные продукты (экраны, защищающие от «непонятных подключений»). И вирусы. Да и сама Windows может стать проблемой. Почти любой ее компонент. Поэтому надо бы проделать следующее:

• Повторно установить NET.Framework. Желательно перед этим удалить предыдущую версию.
• Установить какой-нибудь приличный антивирус (а лучше два) и запустить глубокую проверку систему. Возможно, подключению и входу на ресурс мешает вредоносная программа.
• Если у вас уже установлен антивирус, то, наоборот, попробуйте его отключить. Иногда встроенные в них экраны проверки подключений блокируют работу браузера целиком или отдельных страниц. Лучше выдать браузеру больше прав на выполнение своих задач или установить антивирус, который более лояльно относится к установленному на компьютере софту.
• Еще надо поменять параметры брандмауэра. Его можно разыскать в панели управления Windows. Там надо добавить в список исключений ваш браузер. Тогда брандмауэр не будет мешать подключению к запрашиваемому сайту.
• Почистить Windows от программного мусора. Можно пройтись приложением CCleaner. 
• Обновить драйверы для сетевых устройств. 
• Обновить Windows или просканировать систему на наличие погрешностей в системных компонентах.

Ищем проблему на стороне сервера

Если что-то происходит на стороне ресурса, то это редко заканчивается ошибкой 400. Но все-таки есть несколько сценариев, при которых клиента обвиняют в сбое зря, а настоящая вина лежит на сервере. 

Проверяем требования к HTTP-заголовкам

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

Удаляем свежие обновления и плагины

Иногда ошибка 400 Bad Request появляется после обновления CMS или установки новых плагинов. Если у вас она появилась из-за этого, то наиболее логичное решение — откатиться до более ранней версии CMS и удалить все новые плагины. 

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

Проверяем состояние базы данных

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

Исправляем ошибки в коде и скриптах

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

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

На этом все. Основные причины появления 400 Bad Request разобрали. Как ее лечить — тоже. Теперь дело за вами. Пользуйтесь полученной информацией, чтобы больше не пришлось мучиться в попытках зайти на нужный ресурс.

Как-то писал процедуры в разное время, они работали по-разному для обуви и табака.

&НаКлиенте

Процедура Авторизация(Команда)

    Если ВидМаркировки = «ПолучениеМаркировокОбуви» Тогда

        СтендМаркировки = «ismp.crpt.ru»;

        GetЗапросТекст = «/api/v3/auth/cert/key»;

    ИначеЕсли ВидМаркировки = «ПолучениеМаркировокТабака» Тогда

        СтендМаркировки = «markirovka.crpt.ru»;

        GetЗапросТекст = «/api/v3/true-api/auth/key»; // «/api/v3/auth/simpleSignIn/key»; // «https://ismotp.crptech.ru/api/v3/true-api/auth/key»,0)

    Иначе

        Сообщить(«СтендМаркировки пустой»);

    КонецЕсли;

    хСоединение = Новый HTTPСоединение(СтендМаркировки,443,,,,,Новый ЗащищенноеСоединениеOpenSSL);

    Запрос = Новый HTTPЗапрос(GetЗапросТекст);

    хОтвет = хСоединение.ВызватьHTTPМетод(«GET»,Запрос);

    Если хОтвет.КодСостояния <> 200 ТОгда

        Сообщить(«Ошибка. Код ответа » + хОтвет.КодСостояния);

        Возврат;

    КонецЕсли;

    Сообщение = хОтвет.ПолучитьТелоКакСтроку(«UTF-8»);

    //десериализуем данные о клиенте из JSON

    ЧтениеJSON = Новый ЧтениеJSON;

    ЧтениеJSON.УстановитьСтроку(Сообщение);

    ОборудованиеJSON = ПрочитатьJSON(ЧтениеJSON);

    ЧтениеJSON.Закрыть();

    УИД = ОборудованиеJSON.uuid;

    Данные = ОборудованиеJSON.data;

    Файл = Новый ЗаписьТекста(«D:ылоапыпаорпTempЗагрузкиВыгрузкиcurl_api.txt»);

    Файл.ЗаписатьСтроку(Данные);

    Файл.Закрыть();

    Объект.УИД = СокрЛП(УИД);

    Сообщить(«Подпишите данные в файле на сайте и вставьте в NotePad для изменения n r»);

КонецПроцедуры

Процедура ПолучитьТокенНаСервере()

    Текст = Новый ТекстовыйДокумент;

    ПолноеИмяФайла = «D:ылоапыпаорпTempЗагрузкиВыгрузкиcurl_api.txt»;

    Текст.Прочитать(ПолноеИмяФайла);

    КоличествоСтрок = Текст.КоличествоСтрок();

    Данные = «»;

    Для Счетчик = 1 по КоличествоСтрок Цикл

        ТекСтрока = Текст.ПолучитьСтроку(Счетчик);

        Данные = Данные + ТекСтрока;

    КонецЦикла;

    Если ВидМаркировки = «ПолучениеМаркировокОбуви» Тогда

        ПриефиксЗапроса = «/api/v3/auth/cert/»;

        СтендМаркировки = «ismp.crpt.ru»;

    ИначеЕсли ВидМаркировки = «ПолучениеМаркировокТабака» Тогда

        ПриефиксЗапроса = «/api/v3/true-api/auth/simpleSignIn»;

        СтендМаркировки = «markirovka.crpt.ru»;

    Иначе

        Сообщить(«СтендМаркировки пустой»);

    КонецЕсли;

    Соединение = Новый HTTPСоединение(СтендМаркировки,443,,,,,Новый ЗащищенноеСоединениеOpenSSL);

    Заголовки = Новый Соответствие;

    Заголовки.Вставить(«Content-Type», «application/json; charset=UTF-8»);

    Заголовки.Вставить(«Accept», «application/json»);

    Запрос = Новый HTTPЗапрос(ПриефиксЗапроса,Заголовки);

    ЗаписьJOIN = Новый ЗаписьJSON;

    ЗаписьJOIN.УстановитьСтроку();

    ДанныеДляЗапроса = Новый Структура;

    ДанныеДляЗапроса.Вставить(«uuid»,Объект.УИД);

    ДанныеДляЗапроса.Вставить(«data»,Данные);

    ЗаписатьJSON(ЗаписьJOIN,ДанныеДляЗапроса);

    СтрокаДляЗапроса = ЗаписьJOIN.Закрыть();

    //Формируем ответ клиенту

    Запрос.УстановитьТелоИзСтроки(СтрокаДляЗапроса,КодировкаТекста.UTF8,

    ИспользованиеByteOrderMark.НеИспользовать);

    Ответ = Соединение.ОтправитьДляОбработки(Запрос);

    Если Ответ.КодСостояния <> 200 Тогда

        Сообщить(«Ошибка. Код ответа » + Ответ.КодСостояния);

        ЧтениеJSON = Новый ЧтениеJSON;

        Сообщение = Ответ.ПолучитьТелоКакСтроку(«UTF-8»);

        ЧтениеJSON.УстановитьСтроку(Сообщение);

        СообщениеJSON = ПрочитатьJSON(ЧтениеJSON);

        ЧтениеJSON.Закрыть();

        Сообщить(СообщениеJSON.error_message);

        Возврат;

    КонецЕсли;

    ЧтениеJSON = Новый ЧтениеJSON;

    ЧтениеJSON.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());

    Токен = ПрочитатьJSON(ЧтениеJSON, Ложь).token;

    Объект.Токен = СокрЛП(Токен);

    Константы.Токен.Установить( Объект.Токен);

КонецПроцедуры

&НаКлиенте

Процедура ПолучениеМаркировокОбуви()

    сайт = «ismp.crpt.ru»;

    хСоединение = Новый HTTPСоединение(Сайт,443,,,,,Новый ЗащищенноеСоединениеOpenSSL);

    //Запрос = новый HTTPЗапрос(«/api/v3/facade/identifytools/list?cisStatus=INTRODUCED&limit=10000»);

    Запрос = новый HTTPЗапрос(«/api/v3/facade/identifytools/listV2?cisStatus=INTRODUCED&limit=10000»);

    запрос.Заголовки.Вставить(«Authorization»,»Bearer «+Объект.Токен);

    хОтвет = хСоединение.ВызватьHTTPМетод(«GET»,Запрос);

    Если хОтвет.КодСостояния <> 200 Тогда

        Сообщить(«Ошибка. Код ответа » + хОтвет.КодСостояния);

        ЧтениеJSON = Новый ЧтениеJSON;

        Сообщение = хОтвет.ПолучитьТелоКакСтроку(«UTF-8»);

        ЧтениеJSON.УстановитьСтроку(Сообщение);

        СообщениеJSON = ПрочитатьJSON(ЧтениеJSON);

        ЧтениеJSON.Закрыть();

        Сообщить(СообщениеJSON.error_message);

        Возврат;

    Иначе

        Сообщить(«200 ОК»);

    КонецЕсли;

    Сообщение = хОтвет.ПолучитьТелоКакСтроку(«UTF-8»);

    //десериализуем данные о клиенте из JSON

    ЧтениеJSON = Новый ЧтениеJSON;

    ЧтениеJSON.УстановитьСтроку(Сообщение);

    ОборудованиеJSON = ПрочитатьJSON(ЧтениеJSON);

    ЧтениеJSON.Закрыть();

    Результат = ОборудованиеJSON.results;

    //паралельно Сразу запишем это и в ТЧ и в файл

    РазделительСтрок = «;so»;

    СтрокаЗаписи = «»;

    Файл = Новый ЗаписьТекста(«D:ылоапыпаорпTempЗагрузкиВыгрузкиcurl_api.csv»,КодировкаТекста.ANSI,РазделительСтрок,ЛОЖЬ);

    Объект.ТаблицаВыбывших.Очистить();

    Для Каждого Строка Из Результат Цикл

        НоваяСтрока = Объект.ТаблицаВыбывших.Добавить();

        НоваяСтрока.КИ = Строка.cis;

        НоваяСтрока.gtin = Строка.gtin;

        НоваяСтрока.sgtin = Строка.sgtin;

        НоваяСтрока.Товар = Строка.productName;

        НоваяСтрока.Статус = Строка.status;

        СтрокаЗаписи = СтрокаЗаписи + Строка.gtin + РазделительСтрок + Строка.productName + РазделительСтрок + Строка.status+ РазделительСтрок + «»»» + Строка.cis + «»»» + Символы.ПС;

    КонецЦикла;

    Файл.Записать(СтрокаЗаписи);

    Файл.Закрыть();

КонецПроцедуры

&НаКлиенте

Процедура ПолучениеМаркировокТабака()

    /// /api/v3/true-api/dispenser/tasks&limit=15

    сайт = «markirovka.crpt.ru»; // ismotp.crptech.ru ismotp.crptech.ru/api/v3/true-api – /facade/identifytools/listV2

    хСоединение = Новый HTTPСоединение(Сайт,443,,,,,Новый ЗащищенноеСоединениеOpenSSL);

    СсылкаНастраницу = «/api/v3/true-api/dispenser/tasks»; // фильтрация КИ по табаку owner=»2901289060

    Запрос = новый HTTPЗапрос(СсылкаНастраницу);

    Запрос.Заголовки.Вставить(«Content-Type», «application/json; charset=utf-8»);

    Запрос.Заголовки.Вставить(«Authorization»,»Bearer «+ТокенGET()); // Объект.Токен

    // Чтение тела запроса из файла

    СтрокаJson = ПолучитьТелоЗапросаИзФайла();

    СтрокаJson = СтрЗаменить(СтрокаJson,Символы.ВК,» «);

    СтрокаJson = СтрЗаменить(СтрокаJson,Символы.ПС,» «);

    Запрос.УстановитьТелоИзСтроки(СтрокаJson,КодировкаТекста.UTF8,ИспользованиеByteOrderMark.НеИспользовать);

    хОтвет = хСоединение.ОтправитьДляОбработки(Запрос); //хОтвет = хСоединение.ВызватьHTTPМетод(«POST»,Запрос);

    Если хОтвет.КодСостояния <> 200 Тогда

        Сообщить(«Ошибка. Код ответа » + хОтвет.КодСостояния);

        ЧтениеJSON = Новый ЧтениеJSON;

        Сообщение = хОтвет.ПолучитьТелоКакСтроку(«UTF-8»);

        ЧтениеJSON.УстановитьСтроку(Сообщение);

        СообщениеJSON = ПрочитатьJSON(ЧтениеJSON);

        ЧтениеJSON.Закрыть();

        Сообщить(СообщениеJSON.error_message);

        Возврат;

    Иначе

        Сообщить(«200 ОК»);

    КонецЕсли;

    Сообщение = хОтвет.ПолучитьТелоКакСтроку(«UTF-8»);

    //десериализуем данные о клиенте из JSON

    ЧтениеJSON = Новый ЧтениеJSON;

    ЧтениеJSON.УстановитьСтроку(Сообщение);

    ОборудованиеJSON = ПрочитатьJSON(ЧтениеJSON);

    ЧтениеJSON.Закрыть();

КонецПроцедуры

Описание ошибки:
При попытке выполнить авторизацию на api-сервер Маркировки из модуля МДЛП в 1С 8:
Ошибка при выполнении POST-запроса по адресу /api/v1/auth
[400] Запрос не может быть исполнен.
{«error_code»:»api.authentication.error»,»error_description»:»Ошибка при
выполнении операции: Проверьте аутентификационные данные»}

Найденные решения:

В модуле обмена 1С.Маркировка МДЛП после нажатия на кнопку «Выполнить обмен» и выбора сертификата для подписи при попытке авторизации возникает окно «Не удалось подписать данные» с содержанием ошибки, представленным выше.

Нажатие на изображении увеличит его

Рис.1. Момент возникновения ошибки «Ошибка при выполнении POST-запроса по адресу . /api/v1/auth. Проверьте аутентификационные данные»

Проблема исходя из описания самой ошибки заключается в том, что какие-то данные для подключения не подходят. На этом этапе обычно в промышленном контуре на сайте mdlp.crpt.ru, уже должна быть добавлена «Учётная система» в разделе «Администрирование». Поэтому первым делом необходимо проверить заполнение элемента справочника «Организации МДЛП» для «Собственной организации». Реквизит «Регистрационный номер участника» должен быть использован из профиля организации. А реквизиты «Идентификатор клиента» и «Секретный код» должны совпадать с данными раздела «Администрирование. Учетные системы» кабинета МДЛП для вашей организации. Для API «Промышленной системы» и «Тестовая система МДЛП («Песочница») значение реквизитов отличаются. Это необходимо учитывать и изменить при необходимости.

Нажатие на изображении увеличит его

Рис. 2. Пример с сайта infostart корректности заполнения полей настройки в 1С по данным учетной системы в кабинете МДЛП

Если будут перепутаны и не туда введены какие-либо из трех идентификаторов (рег. номер участника, идентификатор клиента или секретный код), то будет возникать ошибка. Так же если выбран не верный «Адрес API» в «Настройки и справочники» модуля МДЛП в 1С 8. В данном исходно был установлено значение «api.sb.mdlp.crpt.ru». Это не подходило.

Нажатие на изображении увеличит его

Рис. 3. Выбор адреса API в настройках модуля МДЛП в базе 1С 8.

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

Нажатие на изображении увеличит его

Рис. 4. Значение адреса API после выбора значения «Промышленная система».

Оцените, помогло ли Вам предоставленное описание решения ошибки?

© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.

20-09-2022

Журавлев А.С.
(Сайт azhur-c.ru)

Here’s another interesting scenario to discuss.

What if its an type detection API that for instance accepts as input a reference to some locally stored parquet file, and after reading through some metadata of the blocks that compose the file, may realize that one or more of the block sizes exceed a configured threshold and therefor the server decided the file is not partitioning correctly and refuses to start the type detection process.
This validation is there to protect against one of two (or both) scenarios: (1) Long processing time, bad user experience ; (2) Server application explodes with OutOfMemoryError

What would be an appropriate response in this case?

400 (Bad Request) ? — sort of works, generically.

401 (Unauthorized i.e. Unauthenticated) ? — unrelated.

403 (Forbidden i.e. Unauthorized) ? — some would argue it may be somewhat appropriate in this case —

422 (Unprocessable entity) ? — many older answers mention this as appropriate option for input validation failure. What bothers me about using it in my case is the definition of this response code saying its «due to semantic error» while I couldn’t quite understand what semantic error means in that context and whether can we consider this failure indeed as a semantic error failure.

Also the allegedly simple concept of «input» as part of «input validation» can be confusing in cases like this where the physical input provided by the client is only but a pointer, a reference to some entity which is stored in the server, where the actual validation is done on data stored in the server (the parquet file metadata) in conjunction with the action the client tries to trigger (type detection).

413 (PayloadTooLarge)? Going through the different codes I encounter one that may be suitable in my case, one that no one mentioned here so far, that is 413 PayloadTooLarge which I also wonder if it may be suitable or again, not, since its not the actual payload sent in the request that is too large, but the payload of the resource stored in the server.

Which leads me to thinking maybe a 5xx response is more appropriate here.

507 Insufficient Storage ? If we say that «storage» is like «memory» and if we also say that we’re failing fast here with a claim that we don’t have enough memory (or we may blow out with out of memory trying) to process this job, then maybe 507 can me appropriate. but not really.

My conclusion is that in this type of scenario where the server refused to invoke an action on a resource due to space-time related constraints the most suitable response would be 413 PayloadTooLarge

Here’s another interesting scenario to discuss.

What if its an type detection API that for instance accepts as input a reference to some locally stored parquet file, and after reading through some metadata of the blocks that compose the file, may realize that one or more of the block sizes exceed a configured threshold and therefor the server decided the file is not partitioning correctly and refuses to start the type detection process.
This validation is there to protect against one of two (or both) scenarios: (1) Long processing time, bad user experience ; (2) Server application explodes with OutOfMemoryError

What would be an appropriate response in this case?

400 (Bad Request) ? — sort of works, generically.

401 (Unauthorized i.e. Unauthenticated) ? — unrelated.

403 (Forbidden i.e. Unauthorized) ? — some would argue it may be somewhat appropriate in this case —

422 (Unprocessable entity) ? — many older answers mention this as appropriate option for input validation failure. What bothers me about using it in my case is the definition of this response code saying its «due to semantic error» while I couldn’t quite understand what semantic error means in that context and whether can we consider this failure indeed as a semantic error failure.

Also the allegedly simple concept of «input» as part of «input validation» can be confusing in cases like this where the physical input provided by the client is only but a pointer, a reference to some entity which is stored in the server, where the actual validation is done on data stored in the server (the parquet file metadata) in conjunction with the action the client tries to trigger (type detection).

413 (PayloadTooLarge)? Going through the different codes I encounter one that may be suitable in my case, one that no one mentioned here so far, that is 413 PayloadTooLarge which I also wonder if it may be suitable or again, not, since its not the actual payload sent in the request that is too large, but the payload of the resource stored in the server.

Which leads me to thinking maybe a 5xx response is more appropriate here.

507 Insufficient Storage ? If we say that «storage» is like «memory» and if we also say that we’re failing fast here with a claim that we don’t have enough memory (or we may blow out with out of memory trying) to process this job, then maybe 507 can me appropriate. but not really.

My conclusion is that in this type of scenario where the server refused to invoke an action on a resource due to space-time related constraints the most suitable response would be 413 PayloadTooLarge