-Online: http://curl.haxx.se/docs/httpscripting.html
-Date: December 9, 2004
-
- The Art Of Scripting HTTP Requests Using Curl
- =============================================
-
- This document will assume that you're familiar with HTML and general
- networking.
-
- The possibility to write scripts is essential to make a good computer
- system. Unix' capability to be extended by shell scripts and various tools to
- run various automated commands and scripts is one reason why it has succeeded
- so well.
+ _ _ ____ _
+ ___| | | | _ \| |
+ / __| | | | |_) | |
+ | (__| |_| | _ <| |___
+ \___|\___/|_| \_\_____|
+
+
+The Art Of Scripting HTTP Requests Using Curl
+
+ 1. HTTP Scripting
+ 1.1 Background
+ 1.2 The HTTP Protocol
+ 1.3 See the Protocol
+ 1.4 See the Timing
+ 1.5 See the Response
+ 2. URL
+ 2.1 Spec
+ 2.2 Host
+ 2.3 Port number
+ 2.4 User name and password
+ 2.5 Path part
+ 3. Fetch a page
+ 3.1 GET
+ 3.2 HEAD
+ 3.3 Multiple URLs in a single command line
+ 3.4 Multiple HTTP methods in a single command line
+ 4. HTML forms
+ 4.1 Forms explained
+ 4.2 GET
+ 4.3 POST
+ 4.4 File Upload POST
+ 4.5 Hidden Fields
+ 4.6 Figure Out What A POST Looks Like
+ 5. HTTP upload
+ 5.1 PUT
+ 6. HTTP Authentication
+ 6.1 Basic Authentication
+ 6.2 Other Authentication
+ 6.3 Proxy Authentication
+ 6.4 Hiding credentials
+ 7. More HTTP Headers
+ 7.1 Referer
+ 7.2 User Agent
+ 8. Redirects
+ 8.1 Location header
+ 8.2 Other redirects
+ 9. Cookies
+ 9.1 Cookie Basics
+ 9.2 Cookie options
+ 10. HTTPS
+ 10.1 HTTPS is HTTP secure
+ 10.2 Certificates
+ 11. Custom Request Elements
+ 11.1 Modify method and headers
+ 11.2 More on changed methods
+ 12. Web Login
+ 12.1 Some login tricks
+ 13. Debug
+ 13.1 Some debug tricks
+ 14. References
+ 14.1 Standards
+ 14.2 Sites
+
+==============================================================================
+
+1. HTTP Scripting
+
+ 1.1 Background
+
+ This document assumes that you're familiar with HTML and general networking.
The increasing amount of applications moving to the web has made "HTTP
Scripting" more frequently requested and wanted. To be able to automatically
to glue everything together using some kind of script language or repeated
manual invokes.
-1. The HTTP Protocol
+ 1.2 The HTTP Protocol
HTTP is the protocol used to fetch data from web servers. It is a very simple
protocol that is built upon TCP/IP. The protocol also allows information to
request a particular action, and then the server replies a few text lines
before the actual requested content is sent to the client.
- Using curl's option -v will display what kind of commands curl sends to the
- server, as well as a few other informational texts. -v is the single most
- useful option when it comes to debug or even understand the curl<->server
- interaction.
+ The client, curl, sends a 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.
+
+ 1.3 See the Protocol
+
+ Using curl's option --verbose (-v as a short option) will display what kind
+ of commands curl sends to the server, as well as a few other informational
+ texts.
+
+ --verbose is the single most useful option when it comes to debug or even
+ understand the curl<->server interaction.
+
+ Sometimes even --verbose is not enough. Then --trace and --trace-ascii offer
+ even more details as they show EVERYTHING curl sends and receives. Use it
+ like this:
+
+ curl --trace-ascii debugdump.txt http://www.example.com/
+
+ 1.4 See the Timing
+
+ 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'll prepend the time to each trace output line:
+
+ curl --trace-ascii d.txt --trace-time http://example.com/
+
+ 1.5 See the Response
+
+ By default curl sends the response to stdout. You need to redirect it
+ somewhere to avoid that, most often that is done with -o or -O.
2. URL
+ 2.1 Spec
+
The Uniform Resource Locator format is how you specify the address of a
particular resource on the Internet. You know these, you've seen URLs like
- http://curl.haxx.se or https://yourbank.com a million times.
+ https://curl.haxx.se or https://yourbank.com a million times. RFC 3986 is the
+ canonical spec. And yeah, the formal name is not URL, it is URI.
+
+ 2.2 Host
+
+ The host name is usually resolved using DNS or your /etc/hosts file to an IP
+ address and that's what curl will communicate with. Alternatively you specify
+ the IP address directly in the URL instead of a name.
+
+ For development and other trying out situations, you can point to a different
+ IP address for a host name than what would otherwise be used, by using curl's
+ --resolve option:
+
+ curl --resolve www.example.org:80:127.0.0.1 http://www.example.org/
+
+ 2.3 Port number
+
+ Each protocol curl supports operates on a default port number, be it over TCP
+ or in some cases UDP. Normally you don't 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 host name. Like when doing HTTP to port
+ 1234:
+
+ curl http://www.example.org: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 local proxy, and then you may
+ need to specify that proxy's port number separately for what curl needs to
+ connect to locally. Like when using a HTTP proxy on port 4321:
+
+ curl --proxy http://proxy.example.org:4321 http://remote.example.org/
-3. GET a page
+ 2.4 User name and password
- The simplest and most common request/operation made using HTTP is to get a
+ 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.
+
+ You can opt to either insert the user and password in the URL or you can
+ provide them separately:
+
+ curl http://user:password@example.org/
+
+ or
+
+ curl -u user:password http://example.org/
+
+ You need to pay attention that this kind of HTTP authentication is not what
+ is usually done and requested by user-oriented web sites these days. They
+ tend to use forms and cookies instead.
+
+ 2.5 Path part
+
+ 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 host name and possibly port number.
+
+3. Fetch a page
+
+ 3.1 GET
+
+ The simplest and most common request/operation made using HTTP is to GET a
URL. The URL could itself refer to a web page, 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
- curl http://curl.haxx.se
+ curl https://curl.haxx.se
you get a web page returned in your terminal window. The entire HTML document
that that URL holds.
- All HTTP replies contain a set of headers that are normally hidden, use
- curl's -i option to display them as well as the rest of the document. You can
- also ask the remote server for ONLY the headers by using the -I option (which
- will make curl issue a HEAD request).
+ All HTTP replies contain a set of response headers that are normally hidden,
+ use curl's --include (-i) option to display them as well as the rest of the
+ document.
+
+ 3.2 HEAD
+
+ You can ask the remote server for ONLY the headers by using the --head (-I)
+ option which will make 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.
+
+ 3.3 Multiple URLs in a single command line
+
+ 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'll then get requests repeated over and over for all the
+ given URLs.
+
+ Example, send two GETs:
+
+ curl http://url1.example.com http://url2.example.com
+
+ If you use --data to POST to the URL, using multiple URLs means that you send
+ that same POST to all the given URLs.
+
+ Example, send two POSTs:
+
+ curl --data name=curl http://url1.example.com http://url2.example.com
+
+
+ 3.4 Multiple HTTP methods in a single command line
+
+ Sometimes you need to operate on several URLs in a single command line and do
+ different HTTP methods on each. For this, you'll enjoy the --next option. It
+ is basically a separator that separates a bunch of options from the next. All
+ the URLs before --next will get the same method and will get all the POST
+ data merged into one.
-4. Forms
+ When curl reaches the --next on the command line, it'll sort of reset the
+ method and the POST data and allow a new set.
+
+ Perhaps this is best shown with a few examples. To send first a HEAD and then
+ a GET:
+
+ curl -I http://example.com --next http://example.com
+
+ To first send a POST and then a GET:
+
+ curl -d score=10 http://example.com/post.cgi --next http://example.com/results.html
+
+
+4. HTML forms
+
+ 4.1 Forms explained
Forms are the general way a web site can present a HTML page with fields for
- the user to enter data in, and then press some kind of 'OK' or 'submit'
+ 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 track system, display the entered
+ 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.
- Of course there has to be some kind of program in the server end to receive
+ Of course there has to be some kind of program on the server end to receive
the data you send. You cannot just invent something out of the air.
- 4.1 GET
+ 4.2 GET
A GET-form uses the method GET, as specified in HTML like:
To make curl do the GET form post for you, just enter the expected created
URL:
- curl "www.hotmail.com/when/junk.cgi?birthyear=1905&press=OK"
+ curl "http://www.hotmail.com/when/junk.cgi?birthyear=1905&press=OK"
- 4.2 POST
+ 4.3 POST
The GET method makes all input field names get displayed in the URL field of
your browser. That's generally a good thing when you want to be able to
And to use curl to post this form with the same data filled in as before, we
could do it like:
- curl -d "birthyear=1905&press=%20OK%20" www.hotmail.com/when/junk.cgi
+ curl --data "birthyear=1905&press=%20OK%20" \
+ http://www.example.com/when.cgi
This kind of POST will use the Content-Type
application/x-www-form-urlencoded and is the most widely used POST kind.
you need to replace that space with %20 etc. Failing to comply with this
will most likely cause your data to be received wrongly and messed up.
- 4.3 File Upload POST
+ Recent curl versions can in fact url-encode POST data for you, like this:
+
+ curl --data-urlencode "name=I am Daniel" http://www.example.com
+
+ If you repeat --data several times on the command line, curl will
+ concatenate all the given data pieces - and put a '&' symbol between each
+ data segment.
+
+ 4.4 File Upload POST
Back in late 1995 they defined an additional way to post data over HTTP. It
is documented in the RFC 1867, why this method sometimes is referred to as
To post to a form like this with curl, you enter a command line like:
- curl -F upload=@localfilename -F press=OK [URL]
+ curl --form upload=@localfilename --form press=OK [URL]
- 4.4 Hidden Fields
+ 4.5 Hidden Fields
- A very common way for HTML based application to pass state information
+ A very 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 aren't displayed to the user and they get passed
along just as all the other fields.
<input type=submit name="press" value="OK">
</form>
- To post this with curl, you won't have to think about if the fields are
+ To POST this with curl, you won't have to think about if the fields are
hidden or not. To curl they're all the same:
- curl -d "birthyear=1905&press=OK&person=daniel" [URL]
+ curl --data "birthyear=1905&press=OK&person=daniel" [URL]
- 4.5 Figure Out What A POST Looks Like
+ 4.6 Figure Out What A POST Looks Like
When you're about fill in a form and send to a server by using curl instead
of a browser, you're of course very interested in sending a POST exactly the
You will then clearly see the data get appended to the URL, separated with a
'?'-letter as GET forms are supposed to.
-5. PUT
+5. HTTP upload
+
+ 5.1 PUT
- The perhaps best way to upload data to a HTTP server is to use PUT. Then
+ Perhaps the best way to upload data to a 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 a HTTP PUT stream.
Put a file to a HTTP server with curl:
- curl -T uploadfile www.uploadhttp.com/receive.cgi
+ curl --upload-file uploadfile http://www.example.com/receive.cgi
+
+6. HTTP Authentication
-6. Authentication
+ 6.1 Basic Authentication
- Authentication is the ability to tell the server your username and password
- so that it can verify that you're allowed to do the request you're 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.
+ HTTP Authentication is the ability to tell the server your username and
+ password so that it can verify that you're allowed to do the request you're
+ 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.
To tell curl to use a user and password for authentication:
- curl -u name:password www.secrets.com
+ curl --user name:password http://www.example.com
+
+ 6.2 Other Authentication
The site might require a different authentication method (check the headers
returned by the server), and then --ntlm, --digest, --negotiate or even
--anyauth might be options that suit you.
-
+
+ 6.3 Proxy Authentication
+
Sometimes your HTTP access is only available through the use of a HTTP
proxy. This seems to be especially common at various companies. A 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:
- curl -U proxyuser:proxypassword curl.haxx.se
+ curl --proxy-user proxyuser:proxypassword curl.haxx.se
If your proxy requires the authentication to be done using the NTLM method,
use --proxy-ntlm, if it requires Digest use --proxy-digest.
- If you use any one these user+password options but leave out the password
+ If you use any one of these user+password options but leave out the password
part, curl will prompt for the password interactively.
+ 6.4 Hiding credentials
+
Do note that when a program is run, its parameters might be possible to see
when listing the running processes of the system. Thus, other users may be
able to watch your passwords if you pass them as plain command line
options. There are ways to circumvent this.
-7. Referer
+ It is worth noting that while this is how HTTP Authentication works, very
+ many web sites will not use this concept when they provide logins etc. See
+ the Web Login chapter further below for more details on that.
+
+7. More HTTP Headers
+
+ 7.1 Referer
A HTTP request may include a 'referer' field (yes it is misspelled), which
can be used to tell from which URL the client got to this particular
Use curl to set the referer field with:
- curl -e http://curl.haxx.se daniel.haxx.se
+ curl --referer http://www.example.come http://www.example.com
-8. User Agent
+ 7.2 User Agent
Very similar to the referer field, all HTTP requests may set the User-Agent
field. It names what user agent (client) that is being used. Many
is time to set the User Agent field to fool the server into thinking you're
one of those browsers.
- To make curl look like Internet Explorer on a Windows 2000 box:
+ To make curl look like Internet Explorer 5 on a Windows 2000 box:
+
+ curl --user-agent "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" [URL]
- curl -A "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" [URL]
+ Or why not look like you're using Netscape 4.73 on an old Linux box:
- Or why not look like you're using Netscape 4.73 on a Linux (PIII) box:
+ curl --user-agent "Mozilla/4.73 [en] (X11; U; Linux 2.2.15 i686)" [URL]
- curl -A "Mozilla/4.73 [en] (X11; U; Linux 2.2.15 i686)" [URL]
+8. Redirects
-9. Redirects
+ 8.1 Location header
When a resource is requested from a server, the reply from the server may
include a hint about where the browser should go next to find this page, or a
to redirect is Location:.
Curl does not follow Location: headers by default, but will simply display
- such pages in the same manner it display all HTTP replies. It does however
+ such pages in the same manner it displays all HTTP replies. It does however
feature an option that will make it attempt to follow the Location: pointers.
- To tell curl to follow a Location:
-
- curl -L www.sitethatredirects.com
+ To tell curl to follow a Location:
+
+ curl --location http://www.example.com
If you use curl to POST to a site that immediately redirects you to another
- page, you can safely use -L and -d/-F together. Curl will only use POST in
- the first request, and then revert to GET in the following operations.
+ page, you can safely use --location (-L) and --data/--form together. Curl will
+ only use POST in the first request, and then revert to GET in the following
+ operations.
+
+ 8.2 Other redirects
-10. Cookies
+ Browser typically support at least two other ways of redirects that curl
+ doesn't: first the html may contain a meta refresh tag that asks the browser
+ to load a specific URL after a set number of seconds, or it may use
+ javascript to do it.
+
+9. Cookies
+
+ 9.1 Cookie Basics
The way the web browsers do "client side state control" is by using
cookies. Cookies are just names with associated contents. The cookies are
must be able to record and send back cookies the way the web application
expects them. The same way browsers deal with them.
+ 9.2 Cookie options
+
The simplest way to send a few cookies to the server when getting a page with
curl is to add them on the command line like:
- curl -b "name=Daniel" www.cookiesite.com
+ curl --cookie "name=Daniel" http://www.example.com
Cookies are sent as common HTTP headers. This is practical as it allows curl
to record cookies simply by recording headers. Record cookies with curl by
- using the -D option like:
+ using the --dump-header (-D) option like:
- curl -D headers_and_cookies www.cookiesite.com
+ curl --dump-header headers_and_cookies http://www.example.com
- (Take note that the -c option described below is a better way to store
- cookies.)
+ (Take note that the --cookie-jar option described below is a better way to
+ store cookies.)
- Curl has a full blown cookie parsing engine built-in that comes to use if you
+ Curl has a full blown cookie parsing engine built-in that comes in use if you
want to reconnect to a server and use cookies that were stored from a
- previous connection (or handicrafted manually to fool the server into
+ previous connection (or hand-crafted manually to fool the server into
believing you had a previous connection). To use previously stored cookies,
you run curl like:
- curl -b stored_cookies_in_file www.cookiesite.com
+ curl --cookie stored_cookies_in_file http://www.example.com
- Curl's "cookie engine" gets enabled when you use the -b option. If you only
- want curl to understand received cookies, use -b with a file that doesn't
- exist. Example, if you want to let curl understand cookies from a page and
- follow a location (and thus possibly send back cookies it received), you can
- invoke it like:
+ Curl's "cookie engine" gets enabled when you use the --cookie option. If you
+ only want curl to understand received cookies, use --cookie with a file that
+ doesn't exist. Example, if you want to let curl understand cookies from a
+ page and follow a location (and thus possibly send back cookies it received),
+ you can invoke it like:
- curl -b nada -L www.cookiesite.com
+ curl --cookie nada --location http://www.example.com
Curl has the ability to read and write cookie files that use the same file
- format that Netscape and Mozilla do. It is a convenient way to share cookies
- between browsers and automatic scripts. The -b switch automatically detects
- if a given file is such a cookie file and parses it, and by using the
- -c/--cookie-jar option you'll make curl write a new cookie file at the end of
- an operation:
+ format that Netscape and Mozilla once used. It is a convenient way to share
+ cookies between scripts or invokes. The --cookie (-b) switch automatically
+ detects if a given file is such a cookie file and parses it, and by using the
+ --cookie-jar (-c) option you'll make curl write a new cookie file at the end
+ of an operation:
- curl -b cookies.txt -c newcookies.txt www.cookiesite.com
+ curl --cookie cookies.txt --cookie-jar newcookies.txt \
+ http://www.example.com
-11. HTTPS
+10. HTTPS
- There are a few ways to do secure HTTP transfers. The by far most common
+ 10.1 HTTPS is HTTP secure
+
+ There are a few ways to do secure HTTP transfers. By far the most common
protocol for doing this is what is generally known as HTTPS, HTTP over
SSL. SSL encrypts all the data that is sent and received over the network and
thus makes it harder for attackers to spy on sensitive information.
truckload of advanced features to allow all those encryptions and key
infrastructure mechanisms encrypted HTTP requires.
- Curl supports encrypted fetches thanks to the freely available OpenSSL
- libraries. To get a page from a HTTPS server, simply run curl like:
+ Curl supports encrypted fetches when built to use a TLS library and it can be
+ built to use one out of a fairly large set of libraries - "curl -V" will show
+ which one your curl was built to use (if any!). To get a page from a HTTPS
+ server, simply run curl like:
- curl https://that.secure.server.com
+ curl https://secure.example.com
- 11.1 Certificates
+ 10.2 Certificates
In the HTTPS world, you use certificates to validate that you are the one
- you you claim to be, as an addition to normal passwords. Curl supports
- client-side certificates. All certificates are locked with a pass phrase,
- which you need to enter before the certificate can be used by curl. The pass
- phrase can be specified on the command line or if not, entered interactively
- when curl queries for it. Use a certificate with curl on a HTTPS server
- like:
+ you claim to be, as an addition to normal passwords. Curl supports client-
+ side certificates. All certificates are locked with a pass phrase, which you
+ need to enter before the certificate can be used by curl. The pass phrase
+ can be specified on the command line or if not, entered interactively when
+ curl queries for it. Use a certificate with curl on a HTTPS server like:
- curl -E mycert.pem https://that.secure.server.com
+ curl --cert mycert.pem https://secure.example.com
curl also tries to verify that the server is who it claims to be, by
verifying the server's certificate against a locally stored CA cert
bundle. Failing the verification will cause curl to deny the connection. You
- must then use -k in case you want to tell curl to ignore that the server
- can't be verified.
+ must then use --insecure (-k) in case you want to tell curl to ignore that
+ the server can't be verified.
More about server certificate verification and ca cert bundles can be read
in the SSLCERTS document, available online here:
- http://curl.haxx.se/docs/sslcerts.html
+ https://curl.haxx.se/docs/sslcerts.html
+
+ At times you may end up with your own CA cert store and then you can tell
+ curl to use that to verify the server's certificate:
+
+ curl --cacert ca-bundle.pem https://example.com/
-12. Custom Request Elements
+
+11. Custom Request Elements
+
+11.1 Modify method and headers
Doing fancy stuff, you may need to add or change elements of a single curl
request.
For example, you can change the POST request to a PROPFIND and send the data
as "Content-Type: text/xml" (instead of the default Content-Type) like this:
- curl -d "<xml>" -H "Content-Type: text/xml" -X PROPFIND url.com
+ curl --data "<xml>" --header "Content-Type: text/xml" \
+ --request PROPFIND url.com
You can delete a default header by providing one without content. Like you
can ruin the request by chopping off the Host: header:
- curl -H "Host:" http://mysite.com
+ curl --header "Host:" http://www.example.com
You can add headers the same way. Your server may want a "Destination:"
header, and you can add it:
- curl -H "Destination: http://moo.com/nowhere" http://url.com
+ curl --header "Destination: http://nowhere" http://example.com
+
+ 11.2 More on changed methods
+
+ It should be noted that curl selects which methods to use on its own
+ depending on what action to ask for. -d will do POST, -I will do HEAD and so
+ on. If you use the --request / -X option you can change the method keyword
+ curl selects, but you will not modify curl's behavior. This means that if you
+ for example use -d "data" to do a POST, you can modify the method to a
+ PROPFIND with -X and curl will still think it sends a POST. You can change
+ the normal GET to a POST method by simply adding -X POST in a command line
+ like:
+
+ curl -X POST http://example.org/
+
+ ... but curl will still think and act as if it sent a GET so it won't send any
+ request body etc.
+
+
+12. Web Login
+
+ 12.1 Some login tricks
+
+ While not strictly just HTTP related, it still causes a lot of people problems
+ so here's the executive run-down of how the vast majority of all login forms
+ work and how to login to them using curl.
+
+ It can also be noted that to do this properly in an automated fashion, you
+ will most certainly need to script things and do multiple curl invokes etc.
+
+ First, servers mostly use cookies to track the logged-in status of the
+ client, so you will need to capture the cookies you receive in the
+ responses. Then, many sites also set a special cookie on the login page (to
+ make sure you got there through their login page) so you should make a habit
+ of first getting the login-form page to capture the cookies set there.
+
+ Some web-based login systems feature various amounts of javascript, and
+ sometimes they use such code to set or modify cookie contents. Possibly they
+ do that to prevent programmed logins, like this manual describes how to...
+ Anyway, if reading the code isn't enough to let you repeat the behavior
+ manually, capturing the HTTP requests done by your browsers and analyzing the
+ sent cookies is usually a working method to work out how to shortcut the
+ javascript need.
+
+ In the actual <form> tag for the login, lots of sites fill-in random/session
+ or otherwise secretly generated hidden tags and you may need to first capture
+ the HTML code for the login form and extract all the hidden fields to be able
+ to do a proper login POST. Remember that the contents need to be URL encoded
+ when sent in a normal POST.
13. Debug
+ 13.1 Some debug tricks
+
Many times when you run curl on a site, you'll notice that the site doesn't
seem to respond the same way to your curl requests as it does to your
browser's.
browser's requests:
* Use the --trace-ascii option to store fully detailed logs of the requests
- for easier analyzing and better understanding
+ for easier analyzing and better understanding
- * Make sure you check for and use cookies when needed (both reading with -b
- and writing with -c)
+ * Make sure you check for and use cookies when needed (both reading with
+ --cookie and writing with --cookie-jar)
* Set user-agent to one like a recent popular browser does
* Set referer like it is set by the browser
* If you use POST, make sure you send all the fields and in the same order as
- the browser does it. (See chapter 4.5 above)
+ the browser does it.
A very good helper to make sure you do this right, is the LiveHTTPHeader tool
that lets you view all headers you send and receive with Mozilla/Firefox
- (even when using HTTPS).
+ (even when using HTTPS). Chrome features similar functionality out of the box
+ among the developer's tools.
A more raw approach is to capture the HTTP traffic on the network with tools
such as ethereal or tcpdump and check what headers that were sent and
14. References
- RFC 2616 is a must to read if you want in-depth understanding of the HTTP
- protocol.
+ 14.1 Standards
+
+ RFC 7230 is a must to read if you want in-depth understanding of the HTTP
+ protocol
- RFC 2396 explains the URL syntax.
+ RFC 3986 explains the URL syntax
- RFC 2109 defines how cookies are supposed to work.
+ RFC 1867 defines the HTTP post upload format
- RFC 1867 defines the HTTP post upload format.
+ RFC 6525 defines how HTTP cookies work
- http://www.openssl.org is the home of the OpenSSL project
+ 14.2 Sites
- http://curl.haxx.se is the home of the cURL project
+ https://curl.haxx.se is the home of the curl project
projects / platform / upstream / curl.git / blobdiff