I have installed WebDav extensions (--with-http_dav_module,nginx-dav-ext-module) for Nginx, and now I can write, read files using this protocol.
But I need to write data part by part with PUT method, I've found that I can use Content-Range header for this, but I can't find any extension for Nginx to work with Content-Range.
How can I achieve this? Any suggestions?
I can't read data from server and append new data to current and then write it (data is too big).
Using Content-Range for PUT is explicitly forbidden by the HTTP standard, and a really bad idea.
https://www.rfc-editor.org/rfc/rfc7231#section-4.3.4
I wrote a simple specification that allows you to append data:
http://sabre.io/dav/http-patch/
But it does mean that you need to run sabre/dav, and not nginx's webdav module.
Related
I have to implement a HTTP server with some file server capabilities.
I'd already coded HTTP HEAD, GET, PUT, and DELETE requests.
Next thing I need to implement something like RENAME or MOVE to change the name of a file which is already stored on the server. But I cannot find an appropriate HTTP request method for this.
Any idea how to do this or might that be not possible?
Found WebDAV extensions which added a matching HTTP method MOVE for this.
https://tech.yandex.com/disk/doc/dg/reference/move-docpage
http://www.qed42.com/blog/using-curl-commands-webdav
There is also a method MKCOL to create a directory.
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 am working on an HTTP server specifically designed for serving image, video and audio files. I thought that it might be useful to include some metadata in the HTTP response header to describe attributes of the file such as dimensions, duration and codec. This would allow querying this info with a HEAD request, possibly saving the download of the file.
A naive example might look something like this:
X-Media-Duration: 1:23.4
X-Media-Dimensions: (1280px,720px)
X-Media-VideoCodec: h264
Are there any existing standards that perform a similar task? Or, is this not a good idea and why?
Thanks.
Does HTTP PUT have advantages over HTTP POST, particularly for File Uploads? Data transfer should be highly secure. Your ideas / guidance on this will be of great help.
PUT is designed for file uploads moreso than POST which requires doing a multipart upload, but then it comes down to what your server can do as to which is more convenient for you to implement.
Whichever HTTP method you use, you'll be transmitting data in the clear unless you secure the connection using SSL.
I think the choice of PUT vs. POST should be more based on the rule:
PUT to a URL should be used to update or create the resource that can be located at that URL.
POST to a URL should be used to update or create a resource which is located at some other ("subordinate") URL, or is not locatable via http.
Any choices regarding security should work equally with both PUT and POST. https is a good start, if you are building a REST API then keys, authorisation, authentication and message signing are worth investigating.
Does HTTP PUT have advantages over HTTP POST, particularly for File Uploads?
You can use standard tools for sending the data (i.e. ones that don't have to be aware of your custom scheme for describing where the file should be uploaded to or how to represent that file). For example, OpenOffice.org includes WebDAV support.
Data transfer should be highly secure
The method you use has nothing to do with that. For security use SSL in combination with some form of authentication and authorization.
Use-case: Upload a simple image file to a server, which clients could later retrieve
Designate a FTP Server for the job.
HTTP Put: It can directly upload files to a server without the need of a server side
component to handle the bytestream.
HTTP Post: Handle the bytestream by the server side component.
I think to safely use PUT on a public website requires even more effort than using POST (and is less commonly done) due to potential security issues. See http://bitworking.org/news/PUT_SaferOrDangerous.
OTOH, I think there are plenty of resources for safely uploading files with POST and checking them in the server side script, and that this is the more common practice.
PUT is only appropriate when you know the URL you are putting to.
You could also do:
4) POST to obtain a URL to which you then PUT the file.
edit: how are you going to get the HTTP server to decide whether it is OK to accept a particular PUT request?
What I usually do (via PHP) is HTTP POST.
And employ PHP's move_uploaded_file() to get it to whatever destination I want.