The proxy stringcan be specified withaprotocol:// prefix to specify alternative proxy protocols. Use socks4://, socks4a://, socks5:// or socks5h:// to request the specific SOCKS version to be used. No protocol specified, http:// and all others will be treated as HTTP proxies. (The protocol support was added in curl 7.21.7)
Ifthe port number isnotspecified inthe proxy string,it isassumed tobe1080.
Thisoption overrides existing environment variables that set the proxy touse.Ifthere'san environment variable settingaproxy,you can set proxy to""tooverride it.
All operations that are performed over an HTTP proxy will transparently be converted toHTTP.It means that certain protocol specific operations might notbe available.Thisisnotthe caseifyou can tunnel through the proxy,asone with the-p,--proxytunnel option.
User andpassword that might be provided inthe proxy stringare URL decoded by curl.Thisallows you topass inspecial characters such as@by using%40orpass inacolon with%3a.
The proxy host can be specified the exact same way asthe proxy environment variables,including the protocol prefix(http://) and the embedded user + password.
Ifthisoption isused several times,the last one will be used.
Write output toalocal file named like the remote file we get.(Only the file part of the remote file isused,the path iscut off.)
The remote file name touseforsaving isextracted from the given URL,nothing else.
Consequentially,the file will be saved inthe current working directory.Ifyou want the file saved inadifferent directory,make sure you change current working directory before you invoke curl with the-O,--remote-name flag!
There isno URL decoding done on the file name.Ifit has%20orother URL encoded parts of the name,they will endup as-isasfile name.
You may usethisoption asmany times asthe number of URLs you have.
In most cases, the extra performance resulting from the use of oplocks is highly desirable. However, allowing the client to cache data can be a big risk if either the client or network hardware are unreliable. Suppose a client opens a file for writing, creating an oplock on it. When another client also tries to open the file, an oplock break request is sent to the first client. If this request goes unfulfilled for any reason and the second client starts writing to the file, the file can be easily corrupted as a result of the two processes writing to it concurrently. Unfortunately, this scenario is very real. Uncoordinated behavior such as this has been observed many times among Windows clients in SMB networks (with files served by Windows NT/2000 or Samba). Typically, the affected files are database files, which multiple clients open concurrently for writing.
A more concrete example of oplock failure occurs when database files are very large. If a client is allowed to oplock this kind of file, there can be a huge delay while the client copies the entire file from the server to cache it, even though it might need to update only one record. The situation goes from bad to worse when another client tries to open the oplocked file. The first client might need to write the entire file back to the server before the second client’s file open request can succeed. This results in another huge delay (for both clients), which in practice often results in a failed open due to a timeout on the second client, perhaps along with a message warning of possible database corruption!