Запрос функции: /tool fetch HTTP-POST может отправлять файл

Лучше без этого надоедливого ограничения в 4kB или 63KB! К тому же:  
:set $data "up to 63KB..."  
/tool fetch http-method=post http-content-type="application/json" http-data=$data url="https://testserver.lv/index.php"  
https://help.mikrotik.com/docs/display/ROS/Fetch  

Дальше, для скачивания можно использовать «порционную загрузку» (chunking), если сервер это поддерживает. Не знаю, поддерживается ли «порционная загрузка» при отправке данных.

http://forum.mikrotik.com/t/how-to-download-only-one-piece-of-file-at-a-time-with-tool-fetch-and-put-it-inside-a-variable/151020/1

Mikrotik не реализовал способ чтения файлов размером больше 63 КБ. Записывать более крупные файлы можно с помощью команды execute. Думаю, это не документировано, но лимит в 63 КБ для переменных — реальность в ROS 6 и 7. Несколько месяцев назад никто не знал, что можно использовать разбивку на части вместе с переменными в ROS, а теперь это широко применяется.

@msatter Я тоже заинтересован и не нашёл документированного способа загрузить файл в переменную в RouterOS 7, когда файл больше 10 КБ, но меньше 60 КБ.

Это первый пример кода в этой ветке: http://forum.mikrotik.com/t/how-to-download-only-one-piece-of-file-at-a-time-with-tool-fetch-and-put-it-inside-a-variable/151020/1

Ключевой момент — что принимает другая сторона. Предположу, что ты говоришь о curl, который поддерживает опцию «-F» для форм и использование «@» для включения файла. Это зависит от HTML5-элемента <… input=file> внутри формы, а enctype может быть «multipart/form-data» или «x-www-form-urlencoded» (curl по умолчанию выбирает один из вариантов в зависимости от версии и content-type). Так что это ДВА типа загрузки файлов, и есть ещё другие способы. Но в отличие от curl, /tool/fetch никак не помогает с частью data=.

Насколько я знаю, я не видел скриптов, которые собирают нужный MIME или кодируют /file. И если это бинарный файл, даже скрипт может не получить доступ к содержимому файла для отправки или кодирования без дополнительного программирования. Для текстовых файлов, возможно, можно собрать нужные data= для загрузки, но это не просто.

В общем, RouterOS не имеет ни одного примитива для сборки или парсинга HTTP content-type. Он охотно отправит content-type и любые данные, которые ты запишешь в скриптовую переменную типа «str». Но с самой частью данных сегодня он никак не поможет.

Сейчас даже нельзя кодировать или декодировать JSON в массив RouterOS, и это, по моему мнению, ещё большее ограничение. Поэтому нужны скрипты для работы с JSON или расширения вроде «chunk download» от rextended, чтобы обойти проблемы с поддержкой HTTP данных. Может кто-то знает обходной путь с формами и кодированием… но тебе стоит рассмотреть другие варианты передачи файлов, кроме «HTTP загрузки». Например, можно сделать REST API или SFTP на веб-сервере и забирать файл по HTTP-запросу.

Это невозможно. Mikrotik должен добавить поддержку этого. Поскольку у них накопился список багов и других функций, возможно, придётся ждать долго. По сути, /tool/fetch позволяет только отправлять строку (но эта строка может быть любой). В RouterOS нет никаких инструментов для кодирования отправки формы (а файл — это как раз один из типов формы). И ещё, скрипты RouterOS могут читать файлы только до 4 Кб в строку, так что это исключает более продвинутые решения через скрипты.

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

:global filedata [/file get myfile contents]
:put $filedata

Слушай, я не спорю, что в ROS не стоит поддерживать какой-то «файл-аплоад». Я всего лишь говорил, что «загрузка файлов» может происходить по-разному (form-data, WebDAV и прочее) — так что тут не всё так просто, как просто добавлять «files=» в fetch. Ты спрашиваешь: «Должен же быть какой-то обходной путь!»

Вот в чём проблема: как ты и отметил, переменные ограничены по размеру, поэтому в скриптах ROS нельзя закодировать что-то больше 4К. Так что да, возможно, вариантов больше, если бы переменные были больше 4К. Но здесь, скорее всего, дело в том, что переменные в ROS мало чем отличаются от переменных окружения, а в ядре Linux есть ограничение на их размер. Поскольку скрипты должны одинаково работать как на CHR, так и на mAP, это ограничение не может быть слишком большим — иначе скрипты на устройствах с малой памятью сломаются. И «бесконечно большие» переменные — это просто лазейка для переполнений буфера.

Скорее всего, контейнеры (например, Docker) придут первыми, и тогда можно будет просто поднять контейнер, чтобы запустить curl или любой другой нужный метод. Должен ли /tool/fetch иметь больше опций для “curl-форматирования”? За меня бы ты получил голос «за».

+1 за эту функцию

Плюс один за эту функцию