Форматирование вывода тела multipart HTTP-запроса с помощью restsharp

Question

Я создаю запрос restsharp, чтобы вызвать запрос push-запроса пакетной прямой отправки в концентратор уведомлений Azure.

Я получаю ответ 400 Bad Request с сообщением; Не удалось найти часть «уведомлений» в поставляемом многостраничном контенте.

Запрос выглядит так;

const string multipartContentType = "multipart/form-data; boundary=\"simple-boundary\""; 
const string authSignature = "myvalidauthsignature"; 
const string url = "mynotificanhuburl"; 
const string message = "Some message"; 

var restClient = new RestClient 
{ 
    BaseUrl = new Uri(url), 
    Proxy = new WebProxy("127.0.0.1", 8888), 
}; 

var request = new RestSharp.RestRequest(Method.POST) 
{ 
    RequestFormat = DataFormat.Json, 
    AlwaysMultipartFormData = true 
}; 

request.AddHeader("Content-Type", multipartContentType); 
request.AddHeader("Authorization", authSignature); 
request.AddHeader("ServiceBusNotification-Format", "gcm"); 

request.AddParameter("notification", JsonConvert.SerializeObject(new { data = new { message } }), ParameterType.GetOrPost); 
request.AddParameter("devices", JsonConvert.SerializeObject(new List<string> { "123", "456" }), ParameterType.GetOrPost); 

var response = restClient.Execute(request); 

Я могу видеть необработанный запрос через Fiddler;

POST https://xxxxx.servicebus.windows.net/xxx/messages/$batch?direct&api-version=2015-04 HTTP/1.1 
Authorization: [redacted] 
ServiceBusNotification-Format: gcm 
Accept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml 
User-Agent: RestSharp/105.2.3.0 
Content-Type: multipart/form-data; boundary=-----------------------------28947758029299 
Host: [redacted] 
Content-Length: 412 
Accept-Encoding: gzip, deflate 
Connection: Keep-Alive 

-------------------------------28947758029299 
Content-Disposition: form-data; name="notification" 

{"data":{"message":"Some message"}} 
-------------------------------28947758029299 
Content-Disposition: form-data; name="devices" 

["123","456"] 
-------------------------------28947758029299-- 

Которая выглядит правильно. Если я скопирую это в почтальон с заголовками и т. Д., Я могу увидеть тот же ответ об ошибке. HOWEVER в почтовом ящике, когда я удаляю метки кавычек вокруг имен параметров, он работает и возвращает ответ 201.

Так это работает ....

Content-Disposition: form-data; name=notification 

Это не

Content-Disposition: form-data; name="notification" 

Что кажется действительно странным. Однако, поскольку мы используем restsharp, я не думаю, что у меня есть прямой контроль над исходным результатом для тела запроса. Мне интересно;

• Есть restsharp настройки для управления этой котировки, возможно форматированием настройки
• Почему конечная точка Azure отклонить имя параметра в кавычки

Вполне возможно, что этот вопрос находится в другом месте, и это это красная селедка, но это, похоже, несет ответственность.

Цените любую помощь ...

Answer 1

По нашей документации, запрос должен выглядеть следующим образом:

POST https://{Namespace}.servicebus.windows.net/{Notification Hub}/messages/$batch?direct&api-version=2015-08 HTTP/1.1 
Content-Type: multipart/mixed; boundary="simple-boundary" 
Authorization: SharedAccessSignature sr=https%3a%2f%2f{Namespace}.servicebus.windows.net%2f{Notification Hub}%2fmessages%2f%24batch%3fdirect%26api-version%3d2015-08&sig={Signature}&skn=DefaultFullSharedAccessSignature 
ServiceBusNotification-Format: gcm 
Host: {Namespace}.servicebus.windows.net 
Content-Length: 431 
Expect: 100-continue 
Connection: Keep-Alive 


--simple-boundary 
Content-Type: application/json 
Content-Disposition: inline; name=notification 

{"data":{"message":"Hello via Direct Batch Send!!!"}} 
--simple-boundary 
Content-Type: application/json 
Content-Disposition: inline; name=devices 

["Device Token1","Device Token2","Device Token3"] 
--simple-boundary-- 

Таким образом, значение параметра name не котируется (name=devices). Я не нашел RFC, который бы четко определял требования к ситуации. Однако в примерах внутри RFC отображаются значения. И из-за этого я собираюсь исправить службу для поддержки обоих вариантов. Исправление должно появиться после следующего развертывания через неделю или около того.