Could Not Load Program Curl

[Charlotta Menchaca]

Wellthere's the problem. But I don't know why you don't have curl.so as it comes with the php package. You could try re-installing php and seeing if it appears. Alternatively you could compile it yourself and add the .so to the folder.

If you are using JuliaPro and have nothing important in there I would advice uninstalling JuliaPro, deleting C:\Users\vhaglasmithdi\.julia and installing a fresh regular julia (although killing everything may be overkill).

Or do you need specifically JuliaPro?

The official Julia binaries ship with a correct version of libcurl and building it from source also downloads and builds the correct version by default. So one has to make the effort to build Julia against the old, broken system libcurl. I would recommend asking the sysadmin to either upgrade libcurl to something recent or rebuild Julia with its own libcurl. You can also point out that having an old libcurl is a security risk and that especially network code should be kept current.

I do not want to take time from the Discourse group. There are some cloud computing sites sites that provide a Julia environment, either free or at nominal cost. I will make use of those. Perhaps I will come back to Julia at some future time. Thank you.

As similar problems sporadically but regularily pop up here, it would be good if we could find the common cause to this, to be able to solve it. Perhaps there are more than one reasons for this, not always equal to everyone where it happens.

What it needs is someone (or more) who suffers from this AND is willing to put some effort into it to resolve it. With the information we have now, it is very difficult to find a solution. The amount of information I see here on discourse is very little.

Some kind of debug mode the user can switch on, try again, and detailed log metric is written to some file the user could provide.

This would be nice. Or something similar.

Still it needs a user who is willing to help.

The increasing amount of applications moving to the web has made "HTTP Scripting" more frequently requested and wanted. To be able to automatically extract information from the web, to fake users, to post or upload data to web servers are all important tasks today.

Curl is a command line tool for doing all sorts of URL manipulations and transfers, but this particular document focuses on how to use it when doing HTTP requests for fun and profit. This documents assumes that you know how to invoke curl --help or curl --manual to get basic information about it.

Curl is not written to do everything for you. It makes the requests, it gets the data, it sends data and it retrieves the information. You probably need to glue everything together using some kind of script language or repeated manual invokes.

HTTP is the protocol used to fetch data from web servers. It is a simple protocol that is built upon TCP/IP. The protocol also allows information to get sent to the server from the client using a few different methods, as is shown here.

HTTP is plain ASCII text lines being sent by the client to a server to request a particular action, and then the server replies a few text lines before the actual requested content is sent to the client.

The client, curl, sends an HTTP request. The request contains a method (like GET, POST, HEAD etc), a number of request headers and sometimes a request body. The HTTP server responds with a status line (indicating if things went well), response headers and most often also a response body. The "body" part is the plain data you requested, like the actual HTML or the image etc.

Many times you may wonder what exactly is taking all the time, or you just want to know the amount of milliseconds between two points in a transfer. For those, and other similar situations, the --trace-time option is what you need. It prepends the time to each trace output line:

When doing parallel transfers, it is relevant to see which transfer is doing what. When response headers are received (and logged) you need to know which transfer these are for. --trace-ids option is what you need. It prepends the transfer and connection identifier to each trace output line:

The Uniform Resource Locator format is how you specify the address of a particular resource on the Internet. You know these, you have seen URLs like or a million times. RFC 3986 is the canonical spec. The formal name is not URL, it is URI.

The hostname is usually resolved using DNS or your /etc/hosts file to an IP address and that is what curl communicates with. Alternatively you specify the IP address directly in the URL instead of a name.

Each protocol curl supports operates on a default port number, be it over TCP or in some cases UDP. Normally you do not have to take that into consideration, but at times you run test servers on other ports or similar. Then you can specify the port number in the URL with a colon and a number immediately following the hostname. Like when doing HTTP to port 1234:

The port number you specify in the URL is the number that the server uses to offer its services. Sometimes you may use a proxy, and then you may need to specify that proxy's port number separately from what curl needs to connect to the server. Like when using an HTTP proxy on port 4321:

Some services are setup to require HTTP authentication and then you need to provide name and password which is then transferred to the remote site in various ways depending on the exact authentication protocol used.

The path part is just sent off to the server to request that it sends back the associated response. The path is what is to the right side of the slash that follows the hostname and possibly port number.

The simplest and most common request/operation made using HTTP is to GET a URL. The URL could itself refer to a webpage, an image or a file. The client issues a GET request to the server and receives the document it asked for. If you issue the command line

You can ask the remote server for ONLY the headers by using the --head (-I) option which makes curl issue a HEAD request. In some special cases servers deny the HEAD method while others still work, which is a particular kind of annoyance.

The HEAD method is defined and made so that the server returns the headers exactly the way it would do for a GET, but without a body. It means that you may see a Content-Length: in the response headers, but there must not be an actual body in the HEAD response.

A single curl command line may involve one or many URLs. The most common case is probably to just use one, but you can specify any amount of URLs. Yes any. No limits. You then get requests repeated over and over for all the given URLs.

Sometimes you need to operate on several URLs in a single command line and do different HTTP methods on each. For this, you might enjoy the --next option. It is basically a separator that separates a bunch of options from the next. All the URLs before --next get the same method and get all the POST data merged into one.

Forms are the general way a website can present an HTML page with fields for the user to enter data in, and then press some kind of 'OK' or 'Submit' button to get that data sent to the server. The server then typically uses the posted data to decide how to act. Like using the entered words to search in a database, or to add the info in a bug tracking system, display the entered address on a map or using the info as a login-prompt verifying that the user is allowed to see what it is about to see.

In your favorite browser, this form appears with a text box to fill in and a press-button labeled "OK". If you fill in '1905' and press the OK button, your browser then creates a new URL to get for you. The URL gets junk.cgi?birthyear=1905&press=OK appended to the path part of the previous URL.

The GET method makes all input field names get displayed in the URL field of your browser. That is generally a good thing when you want to be able to bookmark that page with your given data, but it is an obvious disadvantage if you entered secret information in one of the fields or if there are a large amount of fields creating a long and unreadable URL.

The data you send to the server MUST already be properly encoded, curl does not do that for you. For example, if you want the data to contain a space, you need to replace that space with %20, etc. Failing to comply with this most likely causes your data to be received wrongly and messed up.

A common way for HTML based applications to pass state information between pages is to add hidden fields to the forms. Hidden fields are already filled in, they are not displayed to the user and they get passed along just as all the other fields.

An easy way to get to see this, is to save the HTML page with the form on your local disk, modify the 'method' to a GET, and press the submit button (you could also change the action URL if you want to).

Perhaps the best way to upload data to an HTTP server is to use PUT. Then again, this of course requires that someone put a program or script on the server end that knows how to receive an HTTP PUT stream.

HTTP Authentication is the ability to tell the server your username and password so that it can verify that you are allowed to do the request you are doing. The Basic authentication used in HTTP (which is the type curl uses by default) is plain text based, which means it sends username and password only slightly obfuscated, but still fully readable by anyone that sniffs on the network between you and the remote server.

Sometimes your HTTP access is only available through the use of an HTTP proxy. This seems to be especially common at various companies. An HTTP proxy may require its own user and password to allow the client to get through to the Internet. To specify those with curl, run something like:

3a8082e126