hVostt, третий раз прошу, ответь на мой вопрос и преведи код метода контроллера. Твой прошлый высер (по незнанию) про MultipartFormDataStreamProvider идёт лесом, ты и сам понимаешь это :)
Попытка номер 10... пока схожу за попкорном.

hVosttПросто я стараюсь использовать инструмент по назначению. Поэтому с этой проблемой не сталкивался. А вот на индусов теперь можно пожаловаться Наделле
Ты не сталкивался с этой "проблемой", но упорно предлагаешь мне что-то советовать. Как тебя понимать?

hVosttА куда ещё большие файлы складывать, в оперативу?
Ни в коей мере. Как вариант, отдавать самому MS SQL в FILESTREAM . Или отдавать другому сервису отпроцессить этот FileStream (популярно для SOA, хостящегося в DMZ). Или просто сливать в файл, да. Но задача стоит стрим на фронте в чистом виде отдать дальше на обработку в другой сервис. Но не в коей мере не в память, убьешь сервер сразу.

hVosttОтматаем назад. Что такое поддержка стримов которой как ты выражаешься нет? Бум разбирать как так получилось, что ты за деревьями леса не разглядел.
Тебе повторить исходную задачу. Ты долго будешь дурачка строить из себя?

P.S. Завтра жди рецепт, я покажу, как можно решить такую ситуацию, как я описал. Но это обход проблемы больше, это не совсем малтипарт.

Вообщем, вот мой вариант: http://codearticles.ru/articles/2445

1. Пакуем в хедеры в base64 нужные парты, в контроллере распаковываем.
2. Основное тело запроса - честный стрим

Плюс подхода: как бы по сути имеем малти парты о всеми вытекающими плюсами, решение подходит для 99% задач.
Минусы подхода: нельзя передать более одного стрима. Точнее можно, но 2 и последующие стримы нужно будет паковать в base64, смысл потоковой передачи идет в топку.

P.S. Для передачи одного стрима с n-дополнительными партами простых типов - то, что доктор прописал.
P.S2. Хвост, ты в следующий раз когда в чем-то не разбираешься, лучше жуй, а не советую, лады? :)
P.S3. WCF наше всё, хоть 100 стримов передавай через параметры

hVosttЯ активно использую WebAPI, и если я не сталкивался с какими-то определёнными проблемами, это не значит, что мне не интересно. Естественно, после твоего мессаджа, я покопал в сторону проблемы и существующих решений. Как оказалось, никакая это не проблема, просто у тебя замыкание в голове. Приспичило тебе понимаешь
1. То, что тебе интересно - я не против, готов тебе много чего рассказать (собственно, постоянно это делаю в рецептах). Просто не нужно умничать в том, в чем еще не разобрался, иначе потом стыдно будет :)
2. Что значит "не проблема"? Я тебе озвучил реальную задачу , WCF (и даже ASMX) щелкает эту задачу на раз-два.

hVosttПолсушай меня очень внимательно. Я конечно могу ошибаться, но задача вебапи принять данные как можно быстрее, и отдать их тебе на обработку.
Файл - это не данные?

hVosttНикакой MS SQL или ещё какая-нибудь пакость не должны принимать в этом процессе непосредственное участие! Причин для этого множество. Неужели клиент отправляя файл должен ждать, пока на сервере заведётся MS SQL и начнёт принимать данные? Нет! Сохранил в память, если объем данных небольшой, или файл если большой -- и делай потом с этим добром что тебе вздумается. Никакой другой сервис участвовать в промежутке не должен.
1. Бред сивой кобылы. MS SQL тут не при чем, я привел тебе один из возможных вариантов.
2. Во-вторых, какую ты проблему видишь в том, чтобы SOA сервис отдал поток в СУБД? Зачем мне тут лишний оверхед на диск и, упаси Боже, в память?
3. Ждать клиенту, пока идет передача, или не ждать - зависит от конкретной реализации и никак не зависит от конечного автомата. Если нужно отпустить клиента, выполняй потоковый аплоад асинхронно, благо возможностей для этого в HttpClient за глаза и с горкой.
4. За "сохранил в память" в печь тебя, ламера. А если таких клиентов у меня 100500, что будет с моей памятью?
5. С какого перепуга ты решил, что другой сервис не должен учавствовать? Да ты, гляжу, мега-архитектор! Это не твоего ума дело, что стоит в бэкэнде, твоя задача во фронте передать поток дальше по назначению. Без оверхедов.

Так что не фантазируй тут. Твоё дело маленькое - сидеть в будке и писать программы по требованию.

hVosttНо если ты упёрся рогом, что надо тебе стрим прям из сети. Да бога ради. Можно и так. Как я уже сказал, причина, почему в библиотеке нет прямой поддержки данной возможности вполне очевидная.
О каком роге речь? Задача элементарная, уровня детского сада. Просто невооруженным глазом виден твой "опыт". Не шарахайся от задач, попытайся вникнуть в их суть.

hVosttСейчас пока времени нет, рецепт твой посмотрю и выкачу решение, как освобожусь.
Никогда не буду против здравой критики.

hVosttмсущко,

убил просто:




а если там мультипарт? ты извращенец! придумываешь какие-то кастомные хедеры, есть же нормальный Content-Disposition. в общем решение полный бред. непонятно на какого клиента рассчитано.
1. Если там малтипарт, проверь его с помощью Request.Content.IsMimeMultipartContent() и если true, не выполняй код. В чем проблема?
2. тавь обработку исключений, проверяй хедер по токенам, колдуй на березовых бруньках - это всё уже твои проблемы, как ты будешь идентифицировать стрим. Главное, что его можно принять без оверхеда.
3. Причем тут Content-Disposition? Чем он мне поможет?

P.S. Не вижу пока никакого бреда, вижу шум и панику неофита, который даже в проблеме не разобрался.

hVosttнепонятно на какого клиента рассчитано.
На моих клиентов и партнеров, которым в мой сервис нужно передать поток с доп. информацией в виде n-полей. В мой сервис на фронте, который расположен в DMZ. У них есть документация к сервису с примерами тел запросов. Всё как обычно в лучших домах Парижа. Если их передача валидна в разрезе бизнес-требований, я пропускаю такое сообщение дальше в бэк-энд для дальнейшего процессинга. Левые клиенты мне не нужны. Что здесь необычного?

АбсолютТак, что в итоге-то? Нормально WebAPI с передачей файла или нет? :D
Жить можно, но черезжопно :) Курим всемогущий WCF и не отвлекаемся на индусячьи игрушки.