Каждый компилировал/устанавливал изображение ядра, создается для одного определенного микропроцессора (или семейство микропроцессоров обычно).
Исходный код частично аппаратно-независим (= много драйверов, планировщиков...) и частично конкретная платформа (= взаимодействие низкого уровня с аппаратными средствами...), но получающийся двоичный файл всегда специфичен для одной архитектуры.
Кажется, что можно пропускать CRLF, промежуточный последний заголовок и полезная нагрузка запроса.
т.е. Вы имеете
POST /restconf/config HTTP/1.1
Host: 127.0.0.1:8080
Accept: */*
Content-Type: application/yang.data+json
{ "toaster:toaster" : { "toaster:toasterManufacturer" : "Geqq", "toaster:toasterModelNumber" : "asaxc", "toaster:toasterStatus" : "_." }}
, и это должно быть
POST /restconf/config HTTP/1.1
Host: 127.0.0.1:8080
Accept: */*
Content-Type: application/yang.data+json
{ "toaster:toaster" : { "toaster:toasterManufacturer" : "Geqq", "toaster:toasterModelNumber" : "asaxc", "toaster:toasterStatus" : "_." }}
В заголовке отсутствовало свойство Content-Length, и сервер считал его обязательным, что, я полагаю, не должно быть обязательным?
После добавления «Content» -Длина заголовка, работает как шарм.
Может быть, это из-за заголовка Content-Type. Если сервер настроен на прием только «application / json», он может вернуть этот код ошибки. Хотя он должен вернуть «415 Unsupported Media Type» согласно RFC2616 .
Это всего лишь предположение, но вы можете попробовать изменить заголовок «Content-Type» на «application / json».
Исходя из вашего сообщения, это должна быть пустая строка перед телом запроса POST. Можете ли вы попробовать добавить один?
Как есть, возможно, сервер видит этот запрос без тела и заголовка вроде:
{ "toaster:toaster" : value
, который объясняет ошибку.