Сбой пакетных запросов веб-API в Postman

Недавно я добавил поддержку пакетных запросов в свой проект веб-API и потратил большую часть дня, пытаясь отладить причину сбоя пакетного запроса с помощью Postman: Unexpected end of MIME multipart stream. MIME multipart message is not complete.

После долгих поисков и изучения всего о конечная проблема с CRLF, я наконец написал быстрое консольное приложение на C #, используя System.Net.Http, похожее на приведенный пример здесь. Это отлично сработало!

У меня вопрос: что делает почтальон по-другому, из-за чего мои пакетные запросы не выполняются? Используя fiddler для захвата запросов, а затем используя winmerge для их сравнения, единственное отличие состоит в том, что запрос Postman содержит несколько дополнительных заголовков:

User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
Cache-Control: no-cache
Origin: chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8

Я попытался добавить эти заголовки в свое консольное приложение, чтобы запросы были точно такими же, и они все еще работали в моем консольном приложении, но не удалось в Postman!

У кого-нибудь есть идеи ПОЧЕМУ?


Запросы, записанные скрипачом ниже:

Почтальон:

POST http://localhost:49402/api/sequentialBatch HTTP/1.1
Host: localhost:49402
Connection: keep-alive
Content-Length: 528
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
Cache-Control: no-cache
Origin: chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm
Session-ID: 03317cfa-c051-4813-a02a-a9fa955cc7f5
Authorization: Basic c2E6c2E=
Content-Type: multipart/mixed; boundary="c3581ff4-f6eb-4c41-ac02-0bb8b80b30ef"
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8

--c3581ff4-f6eb-4c41-ac02-0bb8b80b30ef
Content-Type: application/http; msgtype=request

GET /api/currency?$filter=Currency_ID eq 'Z-US$' HTTP/1.1
Host: localhost.fiddler:49402
Authorization: Basic c2E6c2E=
Session-ID: 03317cfa-c051-4813-a02a-a9fa955cc7f5

--c3581ff4-f6eb-4c41-ac02-0bb8b80b30ef
Content-Type: application/http; msgtype=request

GET /api/countrycode/US HTTP/1.1
Host: localhost.fiddler:49402
Authorization: Basic c2E6c2E=
Session-ID: 03317cfa-c051-4813-a02a-a9fa955cc7f5


--c3581ff4-f6eb-4c41-ac02-0bb8b80b30ef--

КОНСОЛЬНОЕ ПРИЛОЖЕНИЕ: (с дополнительными заголовками почтальона)

POST http://localhost:49402/api/sequentialBatch HTTP/1.1
Host: localhost:49402
Connection: Keep-Alive
Content-Length: 553
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
Cache-Control: no-cache
Origin: chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm
Session-ID: 03317cfa-c051-4813-a02a-a9fa955cc7f5
Authorization: Basic c2E6c2E=
Content-Type: multipart/mixed; boundary="cf2b18a3-5861-49d7-878b-142283cb4959"
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US, en; q=0.8

--cf2b18a3-5861-49d7-878b-142283cb4959
Content-Type: application/http; msgtype=request

GET /api/currency?$filter=Currency_ID%20eq%20'Z-US$' HTTP/1.1
Host: localhost.fiddler:49402
Authorization: Basic c2E6c2E=
Session-ID: 03317cfa-c051-4813-a02a-a9fa955cc7f5


--cf2b18a3-5861-49d7-878b-142283cb4959
Content-Type: application/http; msgtype=request

GET /api/countrycode/US HTTP/1.1
Host: localhost.fiddler:49402
Authorization: Basic c2E6c2E=
Session-ID: 03317cfa-c051-4813-a02a-a9fa955cc7f5


--cf2b18a3-5861-49d7-878b-142283cb4959--

Я заметил одно отличие: в Postman заголовок Content-Length изменился с 553 (как опубликовано) на 528 (после захвата) ... не уверен, имеет ли это отношение к моей проблеме или нет ...


person sǝɯɐſ    schedule 13.08.2014    source источник


Ответы (1)


Было несколько проблем с этим, но я использовал Fiddler. Кажется, что пустой символ возврата имеет значение:

http://prntscr.com/7eq1w1

Это также похоже на разницу между вашим запросом Postman и вашим консольным приложением.

person Michael    schedule 08.06.2015
comment
Проголосовал за ответ, это вполне может быть проблемой. На самом деле мы не стали использовать решение для пакетного запроса, поэтому, к сожалению, у меня больше нет возможности проверить и подтвердить это. Но, возможно, это поможет кому-то другому ... так что спасибо! :) - person sǝɯɐſ; 09.06.2015