Some of the documents in our backend system are read only and dynamically generated when the content is requested. Generating the content for these files is expensive and files of different length are generated over time.
Is there a way I can return an approximate or placeholder content length that isn’t the actual length of the file but when asked for the content via a GET request generate the actual file and return the correct length and content via the stream requests? I tried passing back -1 for the length assuming it could be a magic number to indicate the length is unknown and then repeated IFile.Read requests could be used to return a document of unknown length but that didn't work.
What I want to avoid is generating the content when browsing a directory in Explorer to provide the unknown ContentLength value. Then only when the IFile.Read calls are made generate the document content, cache it and use that cached file to fulfil the content read requests. Is it possible to do this using the ITHit WebDAV engine? Is there another approach to this problem?
It seems like the WebDAV protocol could support returning any content length for documents when browsing a directory but when requesting the content a different / accurate content length could be returned with the content.
The IT Hit WebDAV Server Engine does not support returning unknown file length and here is why:
From our experience, if WebDAV server does not return correct file length both when listing folder content and reading file, some WebDAV clients, such as Microsoft Mini-redirector (Windows Shell) and Microsoft Office will fail to open the document.
Related
I am running lighthttpd in Linux on an embedded platform.
Now i want to make it possible to transfer a file to the system, with an upload web page containing a file selector and "Upload" button (with HTML tags and ). The selected file is transferred as a POST HTTP request containing multipart/form-data. The file should then simply be stored as a regular file in the file system.
I'm already having a CGI interface, a bash script which receives the request and which passes it to the backend C++ application. And because it is an embedded platform, i would like to avoid using php, python etc. only for this case.
As far as i see, lighttpd is not able to save the received files directly from multipart-encoded request body to pure files, correct?
To decode the body i found 'munpack' tool from the mpack package, which writes the encoded body to files on disk, but is intended for mime encoded emails. Nevertheless i can call it in the CGI bash script, and it works almost like expected, except that it can't handle the terminating boundary id (the boundary id given in 'Content-Type' appended by two dashes), resulting in the last file still containing the final boundary. Update: This munpack behaviour came from a faulty script, but still it doesn't work, munpack produces wrong files when the body contains CRLF line endings; only LF produces the correct result.
Is there any other direct request-to-file-on-disk approach? Or do i really have to filter out the terminating boundary manually in the script, or write a multipart-message parser in my C++ application?
To make the use case clear: A user should be able to upload a firmware file to my system. So he connects to my system with a web browser, receives an upload page where he can select the file and send it with an "Upload" button. This transferred file should then simply be stored on my system. The CGI script for receiving the request does already exist (as well as a C++ backend where i could handle the request, too), the only problem is converting the multipart/form-data encoded file to a plain file on disk.
Now i want to make it possible to transfer a file to the system, through a POST HTTP request. The file should simply be stored as a regular file in the file system.
That sounds more like it should be an HTTP PUT rather than an HTTP POST.
As far as i see, lighttpd is not able to save the received files directly from multipart-encoded request body to pure files, correct?
Do you mean application/x-www-form-urlencoded with the POST?
Why multipart-encoded? Are there multiple files being uploaded?
lighttpd mod_webdav supports PUT. Otherwise, you need your own program to handle the request body, be it a shell script or a compiled program. You can use libfcgi with your C++, or you can look at the C programs that lighttpd uses for testing, which implement FastCGI and SCGI in < 300 lines of C each.
I have a file upload API running in IIS. I am calling it from a WPF Application. I have file names like "Test-12345–Coverage–TestFile-2018Jul23".
If you see this file name, it has got a '-' and a '–'. Eventhough they look alike, they are different. Our clients get these filenames generated through some external system, but when I try to upload these files through my webapi. I am getting a 400 Bad request error. It looks like '–' is treated as an invalid character in the http request making it a bad request. If I change '–' to a '-', it works fine.
Is there a list of restricted characters in http request stream objects? If so I would like to know and share it with my clients. There is a debate of application should handle these characters since windows file system allows naming files with these characters. But if IIS rejects it, I don't know what to do. Please advice.
Stream s = System.IO.File.OpenRead("C:\Desktop\Test**-** NoticeInfo **–** funding- July 26, 2018.pdf");
StreamContent content = new StreamContent(stream, Convert.ToInt32(buffer));
_httpClient.PostAsync("http://myurl/api/v1/UploadDocument", content); //The code breaks here
Notice the '-' in the file name. There are two occurences. First one is a standard Keyboard '-'. The second one is a different hyphen. These file names are generated from another system and we are using it to upload in our system. But for some reason IIS did not like the second –, it treats the whole request as a bad request.
How can I detect if a given URL is a file to be downloaded?
I came across the content-disposition header, however it seems that this isn't a part of http 1.1 directly.
Is there a more standard way to detect if the response for a GET request made to a given URL is actually a file to/can be downloaded?
That is the response is not html or json or anything similar, but something like an image, mp3, pdf file etc.?
HTTP is a transfer protocol - which is a very different thing to hard drive storage layouts. The concept of "file" simply does not exist in HTTP. No more than your computer hard drive contains actual paper-and-cardboard "files" that one would see in an office filing system.
Whatever you may think the HTTP message or URL are saying the response content does not have to come from any computer file, and does not have to be stored in one by the recipient.
The response to any GET message in HTTP can always be "downloaded" by sending another GET request with that same URL (and maybe other headers in the case of HTTP/1.1 variants). That is built into the definition of what a GET message is and has nothing to do with files.
I ended up using the content-type to decide if it's an html file or some other type of file that is on the other end of a given URL.
I'm using the content-disposition header content to detect the original file name if it exists since the header isn't available everywhere.
Could checking for a file extension be a possibility? Sorry I can't enlarge on that much without knowing more, but I guess you could consider using PHP to implement this if HTML doesn't have enough functionality?
I want to send a bunch of XML files from my client (iPad) to my application server(Web)..Is there any way I can pass them to server using HTTP POST? I assume HTTP POST only allows embedding strings not attaching as files..We don't want to use FTP due to securuty reasons. We even thought of web service, but not sure whether attachments are possible..Pleas advise if you know any ways of transferring files from client to server.
The maximum length of a POST variable is massive - so no worries there, you can send XML fine. POST can send any type of data, just make sure you set the Content-Type header correctly or you may get unexpected results.
It is no less / more secure than FTP however.
I've implemented a PDF generation function in my flex app using alivePDF, and I'm wondering if the process I've used to get the file to the user creates an XSS vulnerability.
This is the process I'm currently using:
Create the PDF in the flex application.
Send the binary PDF file to the server using a POST, along with the filename to deliver it as.
An ASP.NET script on the server checks the filename to make sure it's valid, and then sends it back to the user as an HTTP attachment.
Given that, what steps should I take to prevent XSS?
Are there any other GET or POST parameters other than the filename?
In preventing XSS, there are three main strategies: validation, escaping, and filtering.
Validation: Upon detecting nvalid characters, reject the POST request (and issue an error to the user).
Escaping: Likely not applicable when saving the file, as your OS will have restrictions on valid file names.
Filtering: Automatically strip the POST filename parameter of any invalid characters. This is what I'd recommend for your situation.
Within the ASP.NET script, immediately grab the POST string and remove the following characters:
< > & ' " ? % # ; +
How is this going to be XSS exploitable? You aren't outputting something directly to the user. The filesystem will just reject strange characters, and when putting the file on the output stream, the name nor the content does matter.