5 \___|\___/|_| \_\_____|
8 The Art Of Scripting HTTP Requests Using Curl
20 2.4 User name and password
31 4.6 Figure Out What A POST Looks Like
34 6. HTTP Authentication
35 6.1 Basic Authentication
36 6.2 Other Authentication
37 6.3 Proxy Authentication
38 6.4 Hiding credentials
49 10.1 HTTPS is HTTP secure
51 11. Custom Request Elements
52 11.1 Modify method and headers
53 11.2 More on changed methods
55 12.1 Some login tricks
57 13.1 Some debug tricks
62 ==============================================================================
68 This document assumes that you're familiar with HTML and general networking.
70 The increasing amount of applications moving to the web has made "HTTP
71 Scripting" more frequently requested and wanted. To be able to automatically
72 extract information from the web, to fake users, to post or upload data to
73 web servers are all important tasks today.
75 Curl is a command line tool for doing all sorts of URL manipulations and
76 transfers, but this particular document will focus on how to use it when
77 doing HTTP requests for fun and profit. I'll assume that you know how to
78 invoke 'curl --help' or 'curl --manual' to get basic information about it.
80 Curl is not written to do everything for you. It makes the requests, it gets
81 the data, it sends data and it retrieves the information. You probably need
82 to glue everything together using some kind of script language or repeated
87 HTTP is the protocol used to fetch data from web servers. It is a very simple
88 protocol that is built upon TCP/IP. The protocol also allows information to
89 get sent to the server from the client using a few different methods, as will
92 HTTP is plain ASCII text lines being sent by the client to a server to
93 request a particular action, and then the server replies a few text lines
94 before the actual requested content is sent to the client.
96 The client, curl, sends a HTTP request. The request contains a method (like
97 GET, POST, HEAD etc), a number of request headers and sometimes a request
98 body. The HTTP server responds with a status line (indicating if things went
99 well), response headers and most often also a response body. The "body" part
100 is the plain data you requested, like the actual HTML or the image etc.
104 Using curl's option --verbose (-v as a short option) will display what kind
105 of commands curl sends to the server, as well as a few other informational
108 --verbose is the single most useful option when it comes to debug or even
109 understand the curl<->server interaction.
111 Sometimes even --verbose is not enough. Then --trace and --trace-ascii offer
112 even more details as they show EVERYTHING curl sends and receives. Use it
115 curl --trace-ascii debugdump.txt http://www.example.com/
119 Many times you may wonder what exactly is taking all the time, or you just
120 want to know the amount of milliseconds between two points in a
121 transfer. For those, and other similar situations, the --trace-time option
122 is what you need. It'll prepend the time to each trace output line:
124 curl --trace-ascii d.txt --trace-time http://example.com/
128 By default curl sends the response to stdout. You need to redirect it
129 somewhere to avoid that, most often that is done with -o or -O.
135 The Uniform Resource Locator format is how you specify the address of a
136 particular resource on the Internet. You know these, you've seen URLs like
137 http://curl.haxx.se or https://yourbank.com a million times. RFC 3986 is the
142 The host name is usually resolved using DNS or your /etc/hosts file to an IP
143 address and that's what curl will communicate with. Alternatively you specify
144 the IP address directly in the URL instead of a name.
146 For development and other trying out situation, you can point out a different
147 IP address for a host name than what would otherwise be used, by using curl's
150 curl --resolve www.example.org:80:127.0.0.1 http://www.example.org/
154 Each protocol curl supports operate on a default port number, be it over TCP
155 or in some cases UDP. Normally you don't have to take that into
156 consideration, but at times you run test servers on other ports or
157 similar. Then you can specify the port number in the URL with a colon and a
158 number immediately following the host name. Like when doing HTTP to port
161 curl http://www.example.org:1234/
163 The port number you specify in the URL is the number that the server uses to
164 offer its services. Sometimes you may use a local proxy, and then you may
165 need to specify that proxy's port number separate on what curl needs to
166 connect to locally. Like when using a HTTP proxy on port 4321:
168 curl --proxy http://proxy.example.org:4321 http://remote.example.org/
170 2.4 User name and password
172 Some services are setup to require HTTP authentication and then you need to
173 provide name and password which then is transferred to the remote site in
174 various ways depending on the exact authentication protocol used.
176 You can opt to either insert the user and password in the URL or you can
177 provide them separately:
179 curl http://user:password@example.org/
183 curl -u user:password http://example.org/
185 You need to pay attention that this kind of HTTP authentication is not what
186 is usually done and requested by user-oriented web sites these days. They
187 tend to use forms and cookies instead.
191 The path part is just sent off to the server to request that it sends back
192 the associated response. The path is what is to the right side of the slash
193 that follows the host name and possibly port number.
200 The simplest and most common request/operation made using HTTP is to get a
201 URL. The URL could itself refer to a web page, an image or a file. The client
202 issues a GET request to the server and receives the document it asked for.
203 If you issue the command line
205 curl http://curl.haxx.se
207 you get a web page returned in your terminal window. The entire HTML document
210 All HTTP replies contain a set of response headers that are normally hidden,
211 use curl's --include (-i) option to display them as well as the rest of the
216 You can ask the remote server for ONLY the headers by using the --head (-I)
217 option which will make curl issue a HEAD request. In some special cases
218 servers deny the HEAD method while others still work, which is a particular
221 The HEAD method is defined and made so that the server returns the headers
222 exactly the way it would do for a GET, but without a body. It means that you
223 may see a Content-Length: in the response headers, but there must not be an
224 actual body in the HEAD response.
230 Forms are the general way a web site can present a HTML page with fields for
231 the user to enter data in, and then press some kind of 'OK' or 'submit'
232 button to get that data sent to the server. The server then typically uses
233 the posted data to decide how to act. Like using the entered words to search
234 in a database, or to add the info in a bug track system, display the entered
235 address on a map or using the info as a login-prompt verifying that the user
236 is allowed to see what it is about to see.
238 Of course there has to be some kind of program in the server end to receive
239 the data you send. You cannot just invent something out of the air.
243 A GET-form uses the method GET, as specified in HTML like:
245 <form method="GET" action="junk.cgi">
246 <input type=text name="birthyear">
247 <input type=submit name=press value="OK">
250 In your favorite browser, this form will appear with a text box to fill in
251 and a press-button labeled "OK". If you fill in '1905' and press the OK
252 button, your browser will then create a new URL to get for you. The URL will
253 get "junk.cgi?birthyear=1905&press=OK" appended to the path part of the
256 If the original form was seen on the page "www.hotmail.com/when/birth.html",
257 the second page you'll get will become
258 "www.hotmail.com/when/junk.cgi?birthyear=1905&press=OK".
260 Most search engines work this way.
262 To make curl do the GET form post for you, just enter the expected created
265 curl "http://www.hotmail.com/when/junk.cgi?birthyear=1905&press=OK"
269 The GET method makes all input field names get displayed in the URL field of
270 your browser. That's generally a good thing when you want to be able to
271 bookmark that page with your given data, but it is an obvious disadvantage
272 if you entered secret information in one of the fields or if there are a
273 large amount of fields creating a very long and unreadable URL.
275 The HTTP protocol then offers the POST method. This way the client sends the
276 data separated from the URL and thus you won't see any of it in the URL
279 The form would look very similar to the previous one:
281 <form method="POST" action="junk.cgi">
282 <input type=text name="birthyear">
283 <input type=submit name=press value=" OK ">
286 And to use curl to post this form with the same data filled in as before, we
289 curl --data "birthyear=1905&press=%20OK%20" \
290 http://www.example.com/when.cgi
292 This kind of POST will use the Content-Type
293 application/x-www-form-urlencoded and is the most widely used POST kind.
295 The data you send to the server MUST already be properly encoded, curl will
296 not do that for you. For example, if you want the data to contain a space,
297 you need to replace that space with %20 etc. Failing to comply with this
298 will most likely cause your data to be received wrongly and messed up.
300 Recent curl versions can in fact url-encode POST data for you, like this:
302 curl --data-urlencode "name=I am Daniel" http://www.example.com
306 Back in late 1995 they defined an additional way to post data over HTTP. It
307 is documented in the RFC 1867, why this method sometimes is referred to as
310 This method is mainly designed to better support file uploads. A form that
311 allows a user to upload a file could be written like this in HTML:
313 <form method="POST" enctype='multipart/form-data' action="upload.cgi">
314 <input type=file name=upload>
315 <input type=submit name=press value="OK">
318 This clearly shows that the Content-Type about to be sent is
321 To post to a form like this with curl, you enter a command line like:
323 curl --form upload=@localfilename --form press=OK [URL]
327 A very common way for HTML based application to pass state information
328 between pages is to add hidden fields to the forms. Hidden fields are
329 already filled in, they aren't displayed to the user and they get passed
330 along just as all the other fields.
332 A similar example form with one visible field, one hidden field and one
333 submit button could look like:
335 <form method="POST" action="foobar.cgi">
336 <input type=text name="birthyear">
337 <input type=hidden name="person" value="daniel">
338 <input type=submit name="press" value="OK">
341 To post this with curl, you won't have to think about if the fields are
342 hidden or not. To curl they're all the same:
344 curl --data "birthyear=1905&press=OK&person=daniel" [URL]
346 4.6 Figure Out What A POST Looks Like
348 When you're about fill in a form and send to a server by using curl instead
349 of a browser, you're of course very interested in sending a POST exactly the
350 way your browser does.
352 An easy way to get to see this, is to save the HTML page with the form on
353 your local disk, modify the 'method' to a GET, and press the submit button
354 (you could also change the action URL if you want to).
356 You will then clearly see the data get appended to the URL, separated with a
357 '?'-letter as GET forms are supposed to.
363 The perhaps best way to upload data to a HTTP server is to use PUT. Then
364 again, this of course requires that someone put a program or script on the
365 server end that knows how to receive a HTTP PUT stream.
367 Put a file to a HTTP server with curl:
369 curl --upload-file uploadfile http://www.example.com/receive.cgi
371 6. HTTP Authentication
373 6.1 Basic Authentication
375 HTTP Authentication is the ability to tell the server your username and
376 password so that it can verify that you're allowed to do the request you're
377 doing. The Basic authentication used in HTTP (which is the type curl uses by
378 default) is *plain* *text* based, which means it sends username and password
379 only slightly obfuscated, but still fully readable by anyone that sniffs on
380 the network between you and the remote server.
382 To tell curl to use a user and password for authentication:
384 curl --user name:password http://www.example.com
386 6.2 Other Authentication
388 The site might require a different authentication method (check the headers
389 returned by the server), and then --ntlm, --digest, --negotiate or even
390 --anyauth might be options that suit you.
392 6.3 Proxy Authentication
394 Sometimes your HTTP access is only available through the use of a HTTP
395 proxy. This seems to be especially common at various companies. A HTTP proxy
396 may require its own user and password to allow the client to get through to
397 the Internet. To specify those with curl, run something like:
399 curl --proxy-user proxyuser:proxypassword curl.haxx.se
401 If your proxy requires the authentication to be done using the NTLM method,
402 use --proxy-ntlm, if it requires Digest use --proxy-digest.
404 If you use any one these user+password options but leave out the password
405 part, curl will prompt for the password interactively.
407 6.4 Hiding credentials
409 Do note that when a program is run, its parameters might be possible to see
410 when listing the running processes of the system. Thus, other users may be
411 able to watch your passwords if you pass them as plain command line
412 options. There are ways to circumvent this.
414 It is worth noting that while this is how HTTP Authentication works, very
415 many web sites will not use this concept when they provide logins etc. See
416 the Web Login chapter further below for more details on that.
422 A HTTP request may include a 'referer' field (yes it is misspelled), which
423 can be used to tell from which URL the client got to this particular
424 resource. Some programs/scripts check the referer field of requests to verify
425 that this wasn't arriving from an external site or an unknown page. While
426 this is a stupid way to check something so easily forged, many scripts still
427 do it. Using curl, you can put anything you want in the referer-field and
428 thus more easily be able to fool the server into serving your request.
430 Use curl to set the referer field with:
432 curl --referer http://www.example.come http://www.example.com
436 Very similar to the referer field, all HTTP requests may set the User-Agent
437 field. It names what user agent (client) that is being used. Many
438 applications use this information to decide how to display pages. Silly web
439 programmers try to make different pages for users of different browsers to
440 make them look the best possible for their particular browsers. They usually
441 also do different kinds of javascript, vbscript etc.
443 At times, you will see that getting a page with curl will not return the same
444 page that you see when getting the page with your browser. Then you know it
445 is time to set the User Agent field to fool the server into thinking you're
446 one of those browsers.
448 To make curl look like Internet Explorer 5 on a Windows 2000 box:
450 curl --user-agent "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" [URL]
452 Or why not look like you're using Netscape 4.73 on an old Linux box:
454 curl --user-agent "Mozilla/4.73 [en] (X11; U; Linux 2.2.15 i686)" [URL]
460 When a resource is requested from a server, the reply from the server may
461 include a hint about where the browser should go next to find this page, or a
462 new page keeping newly generated output. The header that tells the browser
463 to redirect is Location:.
465 Curl does not follow Location: headers by default, but will simply display
466 such pages in the same manner it display all HTTP replies. It does however
467 feature an option that will make it attempt to follow the Location: pointers.
469 To tell curl to follow a Location:
471 curl --location http://www.example.com
473 If you use curl to POST to a site that immediately redirects you to another
474 page, you can safely use --location (-L) and --data/--form together. Curl will
475 only use POST in the first request, and then revert to GET in the following
480 Browser typically support at least two other ways of redirects that curl
481 doesn't: first the html may contain a meta refresh tag that asks the browser
482 to load a specific URL after a set number of seconds, or it may use
489 The way the web browsers do "client side state control" is by using
490 cookies. Cookies are just names with associated contents. The cookies are
491 sent to the client by the server. The server tells the client for what path
492 and host name it wants the cookie sent back, and it also sends an expiration
493 date and a few more properties.
495 When a client communicates with a server with a name and path as previously
496 specified in a received cookie, the client sends back the cookies and their
497 contents to the server, unless of course they are expired.
499 Many applications and servers use this method to connect a series of requests
500 into a single logical session. To be able to use curl in such occasions, we
501 must be able to record and send back cookies the way the web application
502 expects them. The same way browsers deal with them.
506 The simplest way to send a few cookies to the server when getting a page with
507 curl is to add them on the command line like:
509 curl --cookie "name=Daniel" http://www.example.com
511 Cookies are sent as common HTTP headers. This is practical as it allows curl
512 to record cookies simply by recording headers. Record cookies with curl by
513 using the --dump-header (-D) option like:
515 curl --dump-header headers_and_cookies http://www.example.com
517 (Take note that the --cookie-jar option described below is a better way to
520 Curl has a full blown cookie parsing engine built-in that comes to use if you
521 want to reconnect to a server and use cookies that were stored from a
522 previous connection (or hand-crafted manually to fool the server into
523 believing you had a previous connection). To use previously stored cookies,
526 curl --cookie stored_cookies_in_file http://www.example.com
528 Curl's "cookie engine" gets enabled when you use the --cookie option. If you
529 only want curl to understand received cookies, use --cookie with a file that
530 doesn't exist. Example, if you want to let curl understand cookies from a
531 page and follow a location (and thus possibly send back cookies it received),
532 you can invoke it like:
534 curl --cookie nada --location http://www.example.com
536 Curl has the ability to read and write cookie files that use the same file
537 format that Netscape and Mozilla once used. It is a convenient way to share
538 cookies between scripts or invokes. The --cookie (-b) switch automatically
539 detects if a given file is such a cookie file and parses it, and by using the
540 --cookie-jar (-c) option you'll make curl write a new cookie file at the end
543 curl --cookie cookies.txt --cookie-jar newcookies.txt \
544 http://www.example.com
548 10.1 HTTPS is HTTP secure
550 There are a few ways to do secure HTTP transfers. The by far most common
551 protocol for doing this is what is generally known as HTTPS, HTTP over
552 SSL. SSL encrypts all the data that is sent and received over the network and
553 thus makes it harder for attackers to spy on sensitive information.
555 SSL (or TLS as the latest version of the standard is called) offers a
556 truckload of advanced features to allow all those encryptions and key
557 infrastructure mechanisms encrypted HTTP requires.
559 Curl supports encrypted fetches when built to use a TLS library and it can be
560 built to use one out of a fairly large set of libraries - "curl -V" will show
561 which one your curl was built to use (if any!). To get a page from a HTTPS
562 server, simply run curl like:
564 curl https://secure.example.com
568 In the HTTPS world, you use certificates to validate that you are the one
569 you claim to be, as an addition to normal passwords. Curl supports client-
570 side certificates. All certificates are locked with a pass phrase, which you
571 need to enter before the certificate can be used by curl. The pass phrase
572 can be specified on the command line or if not, entered interactively when
573 curl queries for it. Use a certificate with curl on a HTTPS server like:
575 curl --cert mycert.pem https://secure.example.com
577 curl also tries to verify that the server is who it claims to be, by
578 verifying the server's certificate against a locally stored CA cert
579 bundle. Failing the verification will cause curl to deny the connection. You
580 must then use --insecure (-k) in case you want to tell curl to ignore that
581 the server can't be verified.
583 More about server certificate verification and ca cert bundles can be read
584 in the SSLCERTS document, available online here:
586 http://curl.haxx.se/docs/sslcerts.html
588 11. Custom Request Elements
590 11.1 Modify method and headers
592 Doing fancy stuff, you may need to add or change elements of a single curl
595 For example, you can change the POST request to a PROPFIND and send the data
596 as "Content-Type: text/xml" (instead of the default Content-Type) like this:
598 curl --data "<xml>" --header "Content-Type: text/xml" \
599 --request PROPFIND url.com
601 You can delete a default header by providing one without content. Like you
602 can ruin the request by chopping off the Host: header:
604 curl --header "Host:" http://www.example.com
606 You can add headers the same way. Your server may want a "Destination:"
607 header, and you can add it:
609 curl --header "Destination: http://nowhere" http://example.com
611 11.2 More on changed methods
613 It should be noted that curl selects which methods to use on its own
614 depending on what action to ask for. -d will do POST, -I will do HEAD and so
615 on. If you use the --request / -X option you can change the method keyword
616 curl selects, but you will not modify curl's behavior. This means that if you
617 for example use -d "data" to do a POST, you can modify the method to a
618 PROPFIND with -X and curl will still think it sends a POST. You can change
619 the normal GET to a POST method by simply adding -X POST in a command line
622 curl -X POST http://example.org/
624 ... but curl will still think and act as if it sent a GET so it won't send any
630 12.1 Some login tricks
632 While not strictly just HTTP related, it still cause a lot of people problems
633 so here's the executive run-down of how the vast majority of all login forms
634 work and how to login to them using curl.
636 It can also be noted that to do this properly in an automated fashion, you
637 will most certainly need to script things and do multiple curl invokes etc.
639 First, servers mostly use cookies to track the logged-in status of the
640 client, so you will need to capture the cookies you receive in the
641 responses. Then, many sites also set a special cookie on the login page (to
642 make sure you got there through their login page) so you should make a habit
643 of first getting the login-form page to capture the cookies set there.
645 Some web-based login systems features various amounts of javascript, and
646 sometimes they use such code to set or modify cookie contents. Possibly they
647 do that to prevent programmed logins, like this manual describes how to...
648 Anyway, if reading the code isn't enough to let you repeat the behavior
649 manually, capturing the HTTP requests done by your browsers and analyzing the
650 sent cookies is usually a working method to work out how to shortcut the
653 In the actual <form> tag for the login, lots of sites fill-in random/session
654 or otherwise secretly generated hidden tags and you may need to first capture
655 the HTML code for the login form and extract all the hidden fields to be able
656 to do a proper login POST. Remember that the contents need to be URL encoded
657 when sent in a normal POST.
661 13.1 Some debug tricks
663 Many times when you run curl on a site, you'll notice that the site doesn't
664 seem to respond the same way to your curl requests as it does to your
667 Then you need to start making your curl requests more similar to your
670 * Use the --trace-ascii option to store fully detailed logs of the requests
671 for easier analyzing and better understanding
673 * Make sure you check for and use cookies when needed (both reading with
674 --cookie and writing with --cookie-jar)
676 * Set user-agent to one like a recent popular browser does
678 * Set referer like it is set by the browser
680 * If you use POST, make sure you send all the fields and in the same order as
683 A very good helper to make sure you do this right, is the LiveHTTPHeader tool
684 that lets you view all headers you send and receive with Mozilla/Firefox
685 (even when using HTTPS). Chrome features similar functionality out of the box
686 among the developer's tools.
688 A more raw approach is to capture the HTTP traffic on the network with tools
689 such as ethereal or tcpdump and check what headers that were sent and
690 received by the browser. (HTTPS makes this technique inefficient.)
696 RFC 2616 is a must to read if you want in-depth understanding of the HTTP
699 RFC 3986 explains the URL syntax
701 RFC 1867 defines the HTTP post upload format
703 RFC 6525 defines how HTTP cookies work
707 http://curl.haxx.se is the home of the cURL project