简体   繁体   English

解析多格式Mime类型的内容处置字段

[英]Parse a Multi Form Mime Type's Content Disposition Fields

I am writing a native module in C++ for IIS7/8 whose purpose is to reject file uploads coming into IIS with specific extensions. 我正在用IIS7 / 8的C ++语言编写一个本机模块,目的是拒绝带有特定扩展名的文件上传到IIS。

I have gotten the Module working using OnReadEntity and can see the request body on the post request uploading the files. 我已经使用OnReadEntity使模块正常工作,并且可以在上传文件的发布请求中看到请求正文。

However, being pretty inexperienced with c++ I have no idea how I am suppose to reliably parse out the Content-Disposition Fields from the request body so that I can get all of the file names. 但是,由于对C ++缺乏经验,所以我不知道该如何可靠地从请求正文中解析出Content-Disposition字段,以便获得所有文件名。

Below is an example request: 下面是一个示例请求:

------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

Does anyone know if there is something in the httpserv.h API to do this for me already. 有人知道httpserv.h API中是否已有东西可以为我完成此操作。 Or if there is a free non-commercial mime type parser to do this that builds in Visual Studio 2015. 或者,如果有免费的非商业mime类型解析器来执行此操作,该解析器将在Visual Studio 2015中构建。

Or would I need to parse it myself. 还是我需要自己解析。

From what I can gather, Content-Disposition and content-type should always be the 2nd and 3rd lines after a line that starts with ------, The webkitformBoundary differs pending the client making the post (IE, Chrome, FireFox, etc etc). 据我所知,Content-Disposition和content-type应该始终位于以------开头的行之后的第二行和第三行。webkitformBoundary有所不同,取决于客户端发布该帖子(IE,Chrome,FireFox,等)。 Then I would just need to skip to the next ------ if there is one. 然后,如果有一个,我只需要跳到下一个------。

Content-Disposition via the RFC spec states it will always be form-data; 通过RFC规范的Content-Disposition表示它将始终是表格数据; followed by the name of the form field "attach1", and then any data that goes with that input "filename" in the case of an input of type "file". 后跟表单字段“ attach1”的名称,然后在输入类型为“文件”的情况下,随输入“文件名”一起出现的任何数据。

Just looking for points in the right direction on this one. 只是在正确的方向上寻找点。

I already tried using Mimetic, but I couldn't get it to build when I add it's header to my project. 我已经尝试使用Mimetic,但是在将其标头添加到项目中时无法构建它。 The Win32 project it comes with builds, but it won't build in mine. 它附带了Win32项目,但是不会在我的内部构建。

I was able to solve this problem by mixing the CLR with C++ and making my Native Http module a mixed mode DLL. 通过将CLR与C ++混合并使我的Native Http模块成为混合模式DLL,我能够解决此问题。 So it is a native DLL that uses the .Net CLR. 因此,它是使用.Net CLR的本机DLL。

Then using module preConditions I set the module to only run if the .Net CLR is loaded and bitness is 32. 然后使用模块先决条件,我将模块设置为仅在加载.Net CLR且位数为32时运行。

With .Net Enabled I was able to add a reference to System.Net.Http.Formatting, which has a built in MimeType Parser library. 启用.Net后,我可以添加对System.Net.Http.Formatting的引用,该引用具有内置的MimeType Parser库。

Using that I was able to easily parse the Mime type coming in on Post Requests in Begin Request in my Native Http Module, giving me access to the fileName fields on file uploads, which I then used to reject the request if the filename's are blocked extensions and throw a custom 500 internal server error. 使用它,我能够轻松解析本机Http模块中Begin请求中发帖请求中出现的Mime类型,从而使我能够访问文件上传中的fileName字段,然后如果文件名的扩展名被阻止,我便会拒绝该请求并引发自定义500内部服务器错误。

One caveat I found is that sometimes the Entity Body request did not end with a new line character and that breaks the .Net Mime Parsing library, causing an error. 我发现的一个警告是,有时“实体主体”请求没有以换行符结尾,并且破坏了.Net Mime分析库,从而导致错误。 So I check the buffer after I read the Request Entity Body to determine if the last character is a new line character, if not I add one to the buffer by appending it to my .Net Memory Stream after populating it with the raw buffer for use in the .Net Mime Type Parser. 因此,我在读取请求实体正文后检查缓冲区,以确定最后一个字符是否为换行符,否则,我将缓冲区填充了原始缓冲区以供使用,方法是将缓冲区附加到我的.Net内存流中,从而添加一个缓冲区在.Net Mime类型解析器中。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM