Имеется REST API для выгрузки данных на сторонний сервис (интеграция) посредством HTTP POST запроса через форму multipart/form-data.
Общая структура три поля: логин, пароль и прикрепляемый файл данных.
При построении и тестировании запроса в приложении Postman (либо через тот же Curl), все ок, когда файл прикрепляется через интерфейс приложения. Получаю 200 код и валидный ответ.
Но когда я пытаюсь построить тот же самый запрос в приложении php (либо тот же raw в Postman/Curl), то получаю 500 ошибку от сервера, из-за того, что он не может считать файл из http запроса.
Пример запроса:
POST /223/integration/integration/upload HTTP/1.1
Host: 127.0.0.1:223
Connection: Keep-Alive
Cache-Control: no-cache
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryp7MA4YWxkTrZu0gW
----WebKitFormBoundaryp7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="login"
mylogin
----WebKitFormBoundaryp7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="password"
mypassword
----WebKitFormBoundaryp7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="document"; filename="purchaseNotice.xml"
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?> <purchaseProtocolPAAE xmlns="http://zakupki.gov.ru/223fz/purchase/1" xmlns:t="http://zakupki.gov.ru/223fz/types/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://zakupki.gov.ru/223/integration/schema/TFF-2.0/purchase.xsd"> <t:header><t:guid>06adddd4-c7cc-4a5f-a667-7dd3f311bec9</t:guid><t:createDateTime>2013-12-19T16:43:51</t:createDateTime></t:header> <body><item><t:guid>a99d3960-2be6-4baf-aae6-69a4074bd0ec</t:guid><purchaseProtocolPAAEData><guid>e8274477-52e7-4088-9b47-96ae26e93280</guid><createDateTime>2013-12-19T14:49:38</createDateTime><purchaseInfo><t:purchaseNoticeNumber>12345678902</t:purchaseNoticeNumber></purchaseInfo><placer><t:mainInfo><t:inn>3905088712</t:inn><t:kpp>390601001</t:kpp><t:ogrn>1083905000080</t:ogrn></t:mainInfo></placer><customer><t:mainInfo><t:inn>3905088712</t:inn><t:kpp>390601001</t:kpp><t:ogrn>1083905000080</t:ogrn></t:mainInfo></customer><auctionStartDate>2013-12-19T16:40:00</auctionStartDate><auctionEndDate>2013-12-19T16:43:50</auctionEndDate><protocolRZ1Requisites><t:registrationNumber>12345678901-12</t:registrationNumber><t:version>1</t:version></protocolRZ1Requisites><lotApplicationsList><protocolLotApplications><lot><guid>9f36d9bd-3d87-4894-814a-87d295e9a542</guid><ordinalNumber>1</ordinalNumber><subject>Предмет нефтяного договора</subject><initialSumInfo>123.00 руб.</initialSumInfo></lot><lotParameters><nonPrice>0</nonPrice></lotParameters><application><applicationNumber>1</applicationNumber></application><application><applicationNumber>2</applicationNumber></application></protocolLotApplications></lotApplicationsList></purchaseProtocolPAAEData></item></body> </purchaseProtocolPAAE>
----WebKitFormBoundaryp7MA4YWxkTrZu0gWНепонятно, в чем проблема такого способа прикрепления файла. Неверный Content-Type или еще что?
P. S. На header «Host» просьба не обращать внимание, я использую демон stunnel, чтобы данные шифровались и подписывались ЭП при передаче через TLS.
I’m trying to reproduce this Python POST request (verified working) with node.js.
It is a fairly simple POST request sending and receiving XML data.
However, I am getting The request sent by the client was syntactically incorrect errors, despite my XML being valid (verified) and taken directly from the Python example. What am I doing wrong?
My code (reproducible):
// DOC:
// https://wiki.solargis.com/display/public/WS+API+technical+documentation#WSAPItechnicaldocumentation-DatadeliveryWebservice(APIforgettingtimeseriesdata)
// https://nodejs.org/api/http.html#http_http_request_options_callback
// https://nodejs.org/api/http.html#http_request_write_chunk_encoding_callback
// https://nodejs.org/api/https.html
let https = require('https');
const api_key = 'demo';
var request = '<?xml version="1.0" encoding="UTF-8"?>' +
'<ws:dataDeliveryRequest dateFrom="2014-04-28" dateTo="2014-04-28" ' +
'xmlns="http://geomodel.eu/schema/data/request" ' +
'xmlns:ws="http://geomodel.eu/schema/ws/data" ' +
'xmlns:geo="http://geomodel.eu/schema/common/geo" ' +
'xmlns:pv="http://geomodel.eu/schema/common/pv" ' +
'xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">' +
'<site id="demo_site" name="Demo site" lat="48.61259" lng="20.827079"></site>' +
'<processing key="GHI" summarization="HOURLY" terrainShading="true"></processing>' +
'</ws:dataDeliveryRequest>';
var request_utf8 = Buffer.from(request, 'utf-8');
let options = {
host: 'solargis.info',
path: `/ws/rest/pvplanner/calculate?key=${api_key}`,
headers: {
'Content-Type': 'application/xml',
// 'Content-Length': Buffer.byteLength(request),
// 'Transfer-Encoding': 'chunked', //See https://nodejs.org/api/http.html#http_request_write_chunk_encoding_callback
},
method: 'POST',
};
const req = https.request(options, (res) => {
console.log(`STATUS: ${res.statusCode}`);
console.log(`HEADERS: ${JSON.stringify(res.headers)}`);
res.setEncoding('utf8');
res.on('data', (chunk) => {
console.log(`BODY: ${chunk}`);
});
res.on('end', () => {
console.log('No more data in response.');
});
});
req.on('error', (e) => {
console.error(`problem with request: ${e.message}`);
});
// Write data to request body
req.write(request_utf8);
req.end();
The output:
STATUS: 400
HEADERS: {"date":"Wed, 29 Jul 2020 10:00:07 GMT","server":"Apache","set-cookie":["JSESSIONID=4F3F9848F6E115329F6E00624341EB2E.balanced_ws1; Path=/ws/; Secure; HttpOnly"],"content-length":"968","connection":"close","content-type":"text/html;charset=utf-8","x-pad":"avoid browser bug"}
BODY: <html><head><title>Apache Tomcat/7.0.41 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 400 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The request sent by the client was syntactically incorrect.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.41</h3></body></html>
No more data in response.
|
|||
| al_zzz
06.06.19 — 06:29 |
Сегодня при пробитии чека получили такое сообщение: |
||
| Сияющий в темноте
1 — 06.06.19 — 09:01 |
там хранится помарочно вся информация о бутылке,значит и ЕАН тоже. |
||
| Smile 8D
2 — 06.06.19 — 09:40 |
(0) В EAN13 последняя цифра является контрольной, в указанном вами штрих-коде она не валидна. Привязки акциза к штрих-коду товара нет, просто стоит проверка на валидность штрих-кода. В интернете можете почитать как проверяется валидность ean13, а так же найти онлайн-сервисы для проверки штрих-кодов. |
||
|
al_zzz 3 — 06.06.19 — 10:57 |
(2) Спасибо! |
TurboConf — расширение возможностей Конфигуратора 1С
Содержание:
1. Почему появляется эта ошибка 1с 8?
2. Исправление ошибку POST
1. Почему появляется эта ошибка 1с 8?
В процессе работы с 1С порой появляется сообщение «Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm». Данное сообщение достаточно нередко связано с кодом 1С 8.3 в новых релизах 1С.
Рассмотрим, в чем же заключается «неправильность» выполнения запроса POST к ресурсу 1С, каковы первопричины ее образования и как с ней бороться.
В тексте сообщения обычно содержится растолкование источника появления проблемы – это ошибка 1С 8 либо на сервере, либо СУБД, либо какая-то другая.
«Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm» появляется неожиданно и чаще всего не обладает какой-либо логичностью.
2. Исправление ошибку POST
Чтобы исправить ошибку POST к ресурсу /e1cib/logForm можно попробовать сделать следующее:
· Провести типовое Тестирование и Исправлении базы 1С 8 (в конфигураторе в пункте меню «Администрирование» выберите Тестирование и исправление). Предварительно обязательно подготовьте архивную копию базы 1С 8!
· Установить последние актуальные обновления к базе 1С 8.
· Откатить программу 1С до предыдущей версии/релиза (восстановить копию базы 1С, сделанную до выполнения обновления).
· Работая с Windows, можно очистить сеансовые данные. Для этого потребуется остановить службу сервера базы 1С, после чего в папке C:Program Files1cv8srvinforeg_1541snccntx + *уникальный идентификатор* удалить все за исключением файлов, которые имеют расширение *.1, а затем обратно запустить «Сервер 1С».
· Перезапустить сам сервер 1С Предприятие.
· Обратиться на линию консультаций в официальную поддержку фирмы «1С». Кстати, Вы также можете обратиться и к нам по этому или любому другому вопросу. Мы всегда на связи и с радостью поможем решить Вашу проблему.
Специалист компании «Кодерлайн»
Иванова Ольга
Невосстановимая ошибка. Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
Выглядит данная ошибка вот так:
Сначала напишем список предположительных причин данной ошибки, которые Вы можете найти в интернете и которые являются ОШИБОЧНЫМИ:
- Ошибка в релизе 1С
- Ошибка в платформе 1С
- Повреждение базы данных (требующее лечения с помощью «Тестирования и исправления»)
- Ошибка кэша
- Ошибка сервера 1С (предлагается перезапуск службы сервера 1С)
Нет, все перечисленное не имеет отношения к действительности. Иногда проделанные выше действия, кажется, что помогают с исправлением ошибки. Но просто совпадение с решением одновременно реальной причины.
Сложность разбора реальной причины данной проблемы заключается в том, что воспроизводится она непредсказуемым образом.
Замечено, что ошибка воспроизводится практически только при клиент-серверном режиме работы. И обычно при выполнении длительных операций.
«Ошибка при выполнении запроса POST» — есть информация, что ошибка возникает при выполнении длительных, нагруженных операций над базой данных в ситуациях, когда у процесса rphost заканчивается разрешенная оперативная память на процесс.
Нашей рекомендацией является – снять ограничение на количество оперативной памяти на рабочий процесс сервера 1С.
Также может помочь переход с х86 сервера 1С на х64.
Либо иногда может помочь обновление платформы 1С на актуальный релиз и/или перезапуск сервера 1С. Перезапуск понятно, почему помогает. При этом освобождаются ресурсы.
В целом рекомендуем такую ресурсоемкую задачу, как перенос данных 1С, выполнять на мощном оборудовании, с использованием SSD-дисков, если возможно, то файлового режима работы для базы 1С-приемника данных. Если файловый режим невозможен, то рекомендуется использовать только сервер 1С разрядности х64.
Для снятия ограничений на потребление памяти нужно в консоли сервера 1С зайти в свойства рабочего сервера, как показано на скриншоте:
Если для настроек указать значения «-1», как на скриншоте, то данные ограничения для сеансов использоваться не будут. То есть не будет выполняться завершение сеансов, которые потребляют много оперативной памяти.
Используйте эту настройку под свою ответственность. Нужно понимать, что в большинство случаев при параллельной работе большого количества пользователей вы получите стабильную работу сервера 1С все-таки если не будете отключать данную настройку.
Мы рекомендуем устанавливать значения «-1» только на время выполнения задачи переноса данных 1С, либо другой нужной Вам ресурсоемкой задачи.