Регистрация  |  Вход

multipart/form-data попа-боль

Столкнулся с такой проблемой.

Помните такой страшный подход для отправки multipart/form-data POST запросов на сторонние API.
https://salesforce-developer.ru/topic-ot ... sendgrid
или вот про него
https://enreeco.blogspot.com/2013/01/sal ... ata.html

100 лет использую это с разными сервисами и все было норм. Даже у нас на проекте запилил кое какую интеграцию с одним внутренним API. И все было хорошо, но этот внутренний API решили поменять. Ушел старый разраб и пришел новый. Что-то там переписал и отрапортовал что, все можно тесттить. Тестирую а у меня пишет: "Ваша multipart form невалидная".

Ну, думаю, товарищ попал на доработки своего говнокода. А он скидывает мне пример запроса из Postman где все работает и ответ возвращается.

Мистика. Попросил его кусок кода API которым он парсит мой запрос. Думаю что подниму у себя что-то похожее минимально и протестирую сам с собой. Внезапно узнаю что это новый стек - NodeJS + Express. Но когда нас это останавливало.

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

да что за звиздец думаю.

Поднимаю такой же минимальный проект на Python и дергаю иго из SF - работает, запрос принимается, файл получается.

Пробую для чистоты эксперимента посылать multipart/form-data запросы на NodeJS+Express тестовый проект из python и просто из JS из браузера все работает. Из SF нифуа не работает.

И я так и не понял в чем косяк. Пустая форма с полями но без файла работает, с телом файла внутри нет.

Пробовал даже через diff сравнивать исходный текст запросов которые приходят из Postman и из SF - тела абсолютно одинаковые.

Единственное подозрение на то что это как-то связано со спецсимволами, видел какое-то где-то упоминание.

В общем дилема пипец - КТО ЗА ЭТО ДОЛЖЕН ОТВЕЧАТЬ!

У чела работает его новый API на NodeJS + Postman.
У меня до этого все работало с этим API который был на Python.

Получается что он сломал то что работало, но с его точки зрения все работает и наше говнорешение которое мы используем чтобы вручную строить multipart/form-data запрос это наша проблема.

Я согласен кастомное решение проигрывает стандартным проверенным годами либам, но как его исправить я не знаю.

Остается два решения:
Дергать API из браузера напрямую, а на SF посылать только результат, но клиенту надо еще чтобы запросы слались автоматически из Apex Scheduler (браузера уже здесь нет).
И можно поднять Python proxy мини проектик который будет принимать запрос из SF и затем отсылать в NodeJS версию API (Но мне лично этим заниматься лень, да еще за свои бабки сервер поднимать?).

Может кто что посоветует если сталкивались с таким? Просто все время работало это кастомное решение на SF а тут тупо под NodeJS+Express не работает
Столкнулся с такой проблемой.

Помните такой страшный подход для отправки multipart/form-data POST запросов на сторонние API.
https://salesforce-developer.ru/topic-otpravka-attachmentov-v-sendgrid
или вот про него
https://enreeco.blogspot.com/2013/01/salesforce-apex-post-mutipartform-data.html

100 лет использую это с разными сервисами и все было норм. Даже у нас на проекте запилил кое какую интеграцию с одним внутренним API. И все было хорошо, но этот внутренний API решили поменять. Ушел старый разраб и пришел новый. Что-то там переписал и отрапортовал что, все можно тесттить. Тестирую а у меня пишет: "Ваша multipart form  невалидная". 

Ну, думаю, товарищ попал на доработки своего говнокода. А он скидывает мне пример запроса из Postman где все работает и ответ возвращается. 

Мистика. Попросил его кусок кода API которым он парсит мой запрос. Думаю что подниму у себя что-то похожее минимально и протестирую сам с собой. Внезапно узнаю что это новый стек - NodeJS + Express. Но когда нас это останавливало. 

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

да что за звиздец думаю. 

Поднимаю такой же минимальный проект на Python и дергаю иго из SF - работает, запрос принимается, файл получается. 

Пробую для чистоты эксперимента посылать multipart/form-data запросы на NodeJS+Express тестовый проект из python и просто из JS из браузера все работает. Из SF нифуа не работает. 

И я так и не понял в чем косяк. Пустая форма с полями но без файла работает, с телом файла внутри нет.

Пробовал даже через diff сравнивать исходный текст запросов которые приходят из Postman и из SF - тела абсолютно одинаковые.

Единственное подозрение на то что это как-то связано со спецсимволами, видел какое-то где-то упоминание.

В общем дилема пипец - КТО ЗА ЭТО ДОЛЖЕН ОТВЕЧАТЬ!

У чела работает его новый API на NodeJS + Postman.
У меня до этого все работало с этим API который был на Python.

Получается что он сломал то что работало, но с его точки зрения все работает и наше говнорешение которое мы используем чтобы вручную строить multipart/form-data запрос это наша проблема.

Я согласен кастомное решение проигрывает стандартным проверенным годами либам, но как его исправить я не знаю. 

Остается два решения:
Дергать API из браузера напрямую, а на SF посылать только результат, но клиенту надо еще чтобы запросы слались автоматически из Apex Scheduler (браузера уже здесь нет).
И можно поднять Python proxy мини проектик который будет принимать запрос из SF и затем отсылать в NodeJS версию API (Но мне лично этим заниматься лень, да еще за свои бабки сервер поднимать?).

Может кто что посоветует если сталкивались с таким? Просто все время работало это кастомное решение на SF а тут тупо под NodeJS+Express не работает :so-sad::so-sad::so-sad:
Короче решили вопрос. Я в запрос вставляю base64 encoded тело файла. А на стороне API после приема его вручную декодируют обратно в blob перед использованием. Костыли, но хоть так.
Короче решили вопрос. Я в запрос вставляю base64 encoded тело файла. А на стороне API после приема его вручную декодируют обратно в blob перед использованием. Костыли, но хоть так. :sad: