I have implemented a very minimal proof-of-concept supporting a portion of the WebDAV protocol. This includes the OPTIONS, PROPFIND and GET HTTP verbs. The built-in Windows WebDAV client (on Windows 8.1) can therefore open the WebDAV share, list files and directories, and navigate through these.
The GET HTTP verb implementation provides the Accept-Ranges (as bytes), Content-Length, Content-Type and Transfer-Encoding (as chunked). When opening a large video file in a browser, it will begin to play immediately while it is downloading the remaining contents. The built-in WebDAV client of Windows seems to be downloading the entire file to a temporary location prior to having a media player play the file. When a file is 10GB, this is going to suck.
Is there any way to provide support so that the built-in WebDAV client can read ranges of bytes for streaming purposes (I would imagine it just needs to translate to use Range somehow...)?
It sounds like you did all the correct things to indicate to client that streaming is possible, and range requests are possible. So if the client doesn't respond do that, I think you can conclude that it just doesn't support those features. (which is a total bummer).
Related
While trying to setup an streaming server with my raspberry pi, the instructions seem to contain just installing an ftp server.
This made me wonder, what decides whether a file stored in the ftp server to be downloaded or streamed?
In other words, is the choice of downloading or streaming dependent on the client side and not the server side?
If using FTP, streaming is implemented client side using the REST command (for Start Position), as explained at How does a FTP server resume a download? and (in more detail) at http://cr.yp.to/ftp/retr.html .
Your server therefore needs to allow the REST verb (most do by default). Throttling (flow control) is also managed client side.
Long story:
This mechanism is similar to the strategy used by HTTP too. Streaming, however, is a wide subject. and there are other approaches to streaming. Some protocols provide extra verbs to signal other events like changes of bandwidth/resolution to account for unstable connections (like videoconference / desktop share protocols). Some are more suitable for live broadcasting and others for buffered/stored video.
Nowadays, most Streaming Players like YouTube are web based and built on top of the HTTP protocol. Streaming is achieved using the HTTP RANGE Header and by dividing the media in chunks that can be retrieved separately, as explained in this magnific video: https://www.youtube.com/watch?v=OqQk7kLuaK4 .
I have setup a windows 2003 ftp server and using chilkat to connect to this ftp inside my customized application. My application is developed in VB6 with ftp support of chilkat. The application works on different places of the city and connects to my ftp. Unable to access ftp and transfer files using the customised application, from some networks like idea netsetter / bsnl. It works perfect on other networks.
Thanks in advance.
Regards,
Sam
This is likely to be a firewall issue at the client end. FTP is often blocked by firewalls.
Just as well, FTP has its problems making it a less than ideal alternative. There are better options such as SFTP or FTPS but support for those is limited in Windows and you'll have to buy both server and client pieces to use one of them.
Fewer firewalls block HTTP and HTTPS though some are finicky enough to block traffic that doesn't look like Web browsing. Stiil, your odds of success go up substantially.
An obvious choice might be to use WebDAV. IIS supports WebDAV and it is pretty easy to write simple WebDAV client logic in VB6 based on one of the many HTTP components available. I'd probably use XmlHttpRequest or WinHttpRequest for that. A search ought to turn up several VB6 classes written to wrap one of them to support WebDAV client operations. You can also buy WebDAV client libraries.
Stick to using HTTPS (which means you need a server cetificate for IIS) and you won't have passwords going over the network in the clear. Even if you use HTTP you'll be no worse off than using FTP, plus it'll work through the vast majority of firewalls except those that specifically block non-browsing HTTP requests.
This could be a firewall configuration on the Client or Server. You're not going to be able to do much about the client, but for the server it may depend on whether your doing Active or Passive FTP connections.
If you are doing Active connections, make sure ports 20 and 21 are open.
If you're doing Passive connections, you may want to check out this article about configuring the PassivePortRange in Server 2003 FTP- http://support.microsoft.com/?id=555022.
I have an app, and it makes an https connection to a server. Is it possible to use something like wireshark or charlesproxy to just see the useragent that it's connecting with? I don't want to see any of the actual data, just the useragent - but I'm not sure if that is encrypted as well? (and if it's worth trying)
Thanks
Is it possible to...
No. Browser first establishes secure connection with server, then use it for transfer all data including requests' data, various headers etc.
Too late for the original inquirer, but the answer is that it may be possible in some cases, depending on application implementation.
You can use fiddler, and by turning on the 'decrypt https traffic' you also have visibility to the HTTPS content in some cases.
What fiddler does (on windows at least) is register itself within the wininet as system proxy. It can also add certificates (requires your approval when you select to decrypt https traffic) and generates on the fly certificates for the accessed domains, thus being MitM.
Applications using this infrastructure will be 'exposed' to this MitM. I ran fiddler and ran a few applications and was able to view https traffic related to office products (winword, powerpoint, outlook) other MS executables (Searchprotocolhost.exe) but also to some non-microsoft products such as apple software update, cisco jabber)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question 7 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I have to develop a Java application that has to read some files on the network, edit them and put them back.
The problem is that I always did (over the network) file operations through the FTP protocol. But, I recently heard about Webdav which is HTTP based.
Did anyone notice a difference (in terms of speed) between them ? Which one is the best ? Why did they "invent" Webdav if the FTP is good for that?
WebDAV has the following advantages over FTP:
By working via one TCP connection it's easier to configure it to bypass firewalls, NATs and proxies. In FTP the data channel can cause problems with proper NAT setup.
Again due to one TCP connection, which can be persistent, WebDAV would be a bit faster than FTP when transferring many small files - no need to make a data connection for each file.
GZIP compression is a standard for HTTP but not for FTP (yes, MODE Z is offered in FTP, but it's not defined in any standard).
HTTP has wide choice of authentication methods which are not defined in FTP. Eg. NTLM and Kerberos authentication is common in HTTP and in FTP it's hard to get proper support for them unless you write both client and server sides of FTP.
WebDAV supports partial transfers and in FTP partial uploads are not possible (ie. you can't overwrite a block in the middle of the file).
There's one more thing to consider (depending on whether you control the server) - SFTP (SSH File Transfer Protocol, not related to FTP in any way). SFTP is more feature-rich than WebDAV and SFTP is a protocol to access remote file systems, while WebDAV was designed with abstraction in mind (WebDAV was for "documents", while SFTP is for files and directories). SFTP has all benefits mentioned above for WebDAV and is more popular among both admins and developers.
Answer for question - Why did they "invent" Webdav
WebDAV stands for Web Distributed Authoring and Versioning.
Internet was just not meant for consumption of resources through urls (Uniform resource locator)
But that is what it became.
Because HTTP had strong semantics for fetching resources (GET) and (HEAD). (POST) provided coverage for number of semantic operations while (DELETE) was shrouded in distrust. HTTP lacked some other qualities like multi-resource operations.
In nutshell, it was read protocol and not write protocol.
You would go round about to make your resources (URLs) available for fetching by uploading it though FTP and many number of mechanisms.
WebDAV was supposed to provide the missing story of internet : Support for authoring resource through the same mechanism HTTP. It extended its semantics, introduced new HTTP VERBS.
It also introduced the mechanism to not only read, write, modify and delete a resource (uris) but also make inquires on the meta properties of the resource and modify it. It is not that you could not do it before but it was done through back door mechanism.
So you see, it brought some of the same mechanisms that you expect on file operations on desktop to internet resources.
Following are some of the analogies:
MKCOL ----- make collection ----- similar to make folder
PROPGET ---- get properties (meta?) --- same as get info or extended attributes on mac
PROPPATCH --- modify properties
COPY ---- cp
MOVE ---- mv
I hope , I have established some of the noble goals of WebDAV as extension to HTTP to support internet authoring. Not sure if we have achieved it though.
For your question
Your application is a client and will have to make do with what mechanism is available - FTP or WebDAV on the other side. If WebDAV is available great, you can use it. But It will take some time getting used to the semantics. FTP is has limited semantics and excels in simplicity. If you are already using it, don't change it.
Which is faster
That is akin to answering, which is faster HTTP or FTP?
On a sly note, if it was such an issue we wouldn't have been downloading / uploading files via HTTP ;)
Since DAV works over HTTP, you get all the benefits of HTTP that FTP cannot provide.
For example:
strong authentication, encryption, proxy support, and
caching.
It is true that you can get some of this through SSH, but the HTTP infrastructure is much more widely deployed than SSH. Further, SSH does not have the wide complement of tools, development libraries, and applications that HTTP does.
DAV transfers (well, HTTP transfers) are also more efficient than FTP.
You can pipeline multiple transfers through a single TCP connection,
whereas FTP requires a new connection for each file transferred (plus
the control connection).
Reference
Depends on what you want to do.
For example, the overhead on FTP for fetching a list of files is 7 bytes (LIST -a), while it's 370 bytes with Webdav (PROPFIND + 207 Multi Status).
For sending some file, the overhead is lower on FTP than on Webdav, and so on.
If you need to send/fetch a lot of small files, FTP will prove faster (using multiple connections for correct pipelining, and per-file TCP connection).
If you're sending/receiving big files, it's the same on both technology, the overhead will be negligible.
Please see:
http://www.philippheckel.com/files/syncany-heckel-thesis.pdf
Webdav has advantages over FTP regarding easy passing of firewalls (no separate control/data sockets). Speed should be roughly the same as both protocols transfer the file over a raw tcp socket.
file modification time:
there seems to be a difference how ftp and webdav deal with file modification time.
It seems there is a 'command' in ftp to preserve that time (several ftp clients and servers claim to do that), whereas webdav, if I remember correctly, can get the file modification date but can not set it on upload.
owncloud client and some propriatary webdav clients seem to have a workaround, but that works only in their software
depending on usage, that is a stong argument in favour of ftp. I don't want my files to have their modification date == upload date. After a later download, I would not be able to tell by date which version of the file I have.
I'm trying to port a win32 application to Windows Mobile 6 / 6.1 / 6.5. It uses winhttp which doesn't appear to be available on the mobile platforms.
My initial thought was to replace it with WinInet - but I wondered if anyone had a better idea?
WinInet is actually a more appropriate HTTP client library for client nodes.
Here's some things I like about WinInet voer WinHttp:
If your client app needs to make lots of requests from the same server, WinInet will implicitly queue the requests up so as not to flood the server. (But is transparent to the client app). In other words, it respects RFC 2616 guidelines on simultaneous connections. This is great when your app is pulling down a lot of images (or files) from the same server simultanously.
Will the use the IE cache for fetching content. (Which I assume an equivalent cache exists on Mobile platforms).
Proxy server auto-detected from IE settings. Probably less of an issue with mobile since the IP network is a bit more open. But if you had to support proxy servers with WinHttp, you'd have to use other API calls to specify the server directly.
I've used Wininet and it works. But it's not ideal as its timeouts are broken. And developing a complete asynchronous design with it required a ton of code.
So instead, I'm trying libcurl.
So far though, I still haven't managed to get it compile properly and link. Porting stuff is such a pain sometimes. But I digress. ;)