Разобрать поля расположения содержимого мультиформного Mime-типа

Я пишу собственный модуль на C ++ для IIS7 / 8, целью которого является запрет загрузки файлов, поступающих в IIS с определенными расширениями.

Я получил модуль, работающий с использованием OnReadEntity, и могу видеть тело запроса после отправки запроса на загрузку файлов.

Тем не менее, будучи довольно неопытным с c ++, я понятия не имею, как я должен надежно анализировать поля Content-Disposition из тела запроса, чтобы я мог получить все имена файлов.

Ниже приведен пример запроса:

------WebKitFormBoundaryUomVPwKHGvBwvDhP
Content-Disposition: form-data; name="attach1"; filename="YSMIsapiFilter.sln"Content-Type: text/plain

SomeDataHere

------WebKitFormBoundaryUomVPwKHGvBwvDhP
Content-Disposition: form-data; name="attach2"; filename="ysmISAPIFilter.log"Content-Type: application/octet-stream

I AM A LOG
------WebKitFormBoundaryUomVPwKHGvBwvDhP
Content-Disposition: form-data; name="enter_a_number"

------WebKitFormBoundaryUomVPwKHGvBwvDhP--
ol: max-age=0
Connection: keep-alive
Accept:     text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: ASPSESSIONIDSSSRCTRS=GHMFFGABJAAOAEHFCFIOOJIO
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like                         Gecko) Chrome/49.0.2623.110 Safari/537.36
Upgrade-Insecure-Requests: 1

Кто-нибудь знает, есть ли что-то в API httpserv.h, чтобы сделать это для меня уже. Или, если для этого есть бесплатный некоммерческий анализатор MIME-типов, который собирается в Visual Studio 2015.

Или мне нужно разобрать это самому.

Из того, что я могу собрать, Content-Disposition и content-type всегда должны быть 2-й и 3-й строками после строки, начинающейся с ——, webkitformBoundary отличается в зависимости от того, как клиент делает сообщение (IE, Chrome, FireFox, и т. д.) Тогда мне просто нужно перейти к следующему ——, если есть.

Content-Disposition через спецификацию RFC утверждает, что это всегда будут form-data; за которым следует имя поля формы «attach1», а затем любые данные, которые идут с этим вводом «filename» в случае ввода типа «file».

Просто ищу точки в правильном направлении на этом.

Я уже пытался использовать Mimetic, но не смог его создать, когда добавил заголовок в свой проект. Проект Win32 поставляется со сборками, но не собирается в моем.

0

Решение

Я смог решить эту проблему, смешав CLR с C ++ и превратив свой модуль Native Http в DLL в смешанном режиме. Так что это нативная DLL, которая использует .Net CLR.

Затем, используя предварительные условия для модуля, я настраиваю модуль на запуск только в том случае, если загружен .Net CLR и битность равна 32.

С включенным .Net я смог добавить ссылку на System.Net.Http.Formatting, который имеет встроенную библиотеку MimeType Parser.

Используя это, я смог легко проанализировать тип Mime, входящий в Post Requests в Begin Request в моем родном Http-модуле, предоставляя мне доступ к полям fileName при загрузке файлов, которые я затем использовал для отклонения запроса, если имена файлов заблокированы расширениями. и выбрасываю пользовательскую 500 внутреннюю ошибку сервера.

Одно замечание, которое я обнаружил, заключается в том, что иногда запрос Entity Body не заканчивался символом новой строки, и это нарушает библиотеку .Net Mime Parsing, вызывая ошибку. Поэтому я проверяю буфер после прочтения тела объекта запроса, чтобы определить, является ли последний символ символом новой строки, если нет, я добавляю его в буфер, добавляя его в мой поток памяти .Net после заполнения его необработанным буфером для использования. в .Net Mime Type Parser.

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]