Professional Documents
Culture Documents
Home
About
Events
Open Source
Vote for a Topic
Write for Techportal
Select a page
Getting Set Up
You can download Charles Proxy from the project website: http://www.charlesproxy.com/.
Under the Documentation section you will find instructions for installing the tool onto
whichever platform you use (Charles supports Windows, Mac and Linux).
Firefox Extension
Charles oers a Firefox extension from its download page that makes it very easy to start using
your web applications with Charles immediately. Once you have the extension installed, simply
run Charles and then enable the extension from the Tools menu in Firefox. When a web request
is made in Firefox, the HTTP trac involved is routed through Charles. This is a great way to
get started and is the approach used to generate the first few examples in this article.
A more linear way to look at the trac is to use the Sequence tab, which will show something
like this:
Where to look next depends entirely what youre looking for. The filter box (below the sequence
of requests and above the detail section) is very smart, including the ability to configure it to
use a regular expression in its search, and will search all the fields shown in the grid. This
allows you to filter down the results to just requests with a given response or using a particular
verb, or to a particular domain or subdomain.
Once you have identified the request you want to see, check out the tabs in the bottom half of
the screen. These typically show the following options:
Overview: Some summary information about the request and response formats,
sizes, time taken, and so on. This can be useful when comparing similar requests.
Request: Full, detailed information about the request, headers, data sent. Look at
the dierent aspects using the tabs along the bottom of the window.
Response: Much like the request tab, the response tab has some very nice feaures,
in particular its ability to nicely represent data formats such as JSON which can be
viewed raw, pretty-printed, or parsed into a structure you can drill down into.
Summary: Shows all the requests that were made as a result of this request, such
as loading other assets to display the page, plus information about the overall size
and time of these. Mostly useful when requesting a root page which loads in other
elements such as images.
Chart: Also mostly useful when requesting a page that loads other elements, this
gives a timing diagram of things arriving as shown in the figure below:
Armed with this information, you can take a good look at whats taking the time in your
application, which pages are pulling in which other pages, and so on. Once you have identified
where a problem exists, we can use the following techniques to further diagnose or observe it.
Replay a Request
Charles oers the ability to repeat a specific request as many times as you want to. Either
right-click on the request to see the options and choose repeat, or press the blue circular
arrows button on the toolbar to repeat the request. As a debugging tool, this is much nicer than
having to fill in the same web form lots of times, or otherwise follow a tricky, multi-step process
to replicate a bug.
The right-click menu also oers the ability to repeat advanced, which allows the same
request to be made to the server multiple times, including the option to specify the
concurrency. If you are seeing weirdness under load or you suspect a race condition, then this
feature is your friend!
Sharing Requests
Its possible to import and export sessions with Charles, in HAR (HTTP ARchive) format, which
is supported by other tools as well. This is superbly handy when one developer is seeing a
problem and wants to show another one whats happening without the aforementioned tricky
process to reproduce the bug. Simply export your session from Charles and add it as an
attachment in the bug tracker; whether it is you or someone else that picks this up, it makes it
very easy to replicate the problem and be able to begin working on a fix.
Throttling Requests
This is a really good use of a local proxy; to throttle the trac going through your browser in
order to simulate a particular setup or network speed. For websites where it is likely that the
user is either using a mobile phone or is connected via a mobile data connection, this gives us,
as developers, insight into how the user experience will be in that scenario.
Charles oers a few options for speed restrictions to simulate dierent kinds of network
connection, shown in the screenshot below:
It is also possible to limit throttling to just a particular set of hosts, so if for example you know
that one particular 3rd party may provide slow connection speeds in some situations, then you
can narrow that down using these settings.
Throttling is a very important step in testing mobile applications, especially when working with
either mobile sites or with app simulators, since it gives a more realistic sense of the user
experience. I lead an open source project (http://joind.in) which is used mostly at conferences,
and conference wifi is usually fairly awful so I throttle down to old modem speeds to give
myself a sense of experience when developing that site.
Another feature of Charles which is relevant to this area of development is that it can disable
caching. This enables you to reproduce the experience that a new visitor to your site will see.
To achieve this, Charles changes the headers in the HTTP trac, a feature that we can take
direct advantage of ourselves.
As you can see, the options here are endless. There are any number of reasons why you might
need to add things, but these are my most common use cases:
Injecting extra headers, either so that I can track a journey through the
site because the additional information gets added to a log file, or to
enable additional debugging.
Injecting response headers to see how a client would react on receiving
these from a server. HTTP supports the use of custom headers, so in
theory you can use any header you like so long as your server knows
how to understand it, and the RFC (see RFC 2616) recommends picking
a prefix. In practice, its common to use X- as the prefix for these
invented headers.
Modifying headers to alter a User-Agent header to chase down a
particular bug.
Setting Host headers easily the most-used, mostly when using other
machines or devices on a network to hit a local development virtual host
with a dierent domain name than expected by the application (more on
this in the next section showing how I develop with mobile devices
against my local development machine via Charles).
Adding a rule to do a find-and-replace on the body of a request or
response is also very useful at times, for example to rewrite links.
These are very useful tools and the biggest advantage is that you dont need to recompile or
reconfigure either the client or server to make these changes; Charles can intercept the trac
and make the changes on the fly. When developing a mobile app, where you might want to
change whether it hits live or development copies of the back end API for example, this is a
very quick and easy way to do it. It also protects against hardcoding these changes into your
application and then finding that they get erroneously committed and deployed.
First, check the IP address of your machine, and check or set which port Charles will listen on
by looking under Proxy, then Proxy Settings. By default this is 8888, and in this example my
machine has the IP 10.1.0.121.
Add either the machine hostname or IP to the device to proxy under the wifi settings for the
shared network. Im using an Android phone as Ive been looking at the updated Android app
for joind.in, although do be aware that some versions of Android (stock ROMs in the 2.x series,
also known as bug 1273) do not allow you to specify a proxy when adding network settings.
When you try to make a web request from the phone now, Charles will alert you that something
is trying to proxy through, and give you the opportunity to allow or deny the access:
While working with the mobile app, this is a very easy way to observe the trac being sent and
received, and to spot any errors that might be silently ignored or not handled by the application
(particularly as my application is in very early stages).
At this point we have the opportunity to perform all of the filtering and altering of trac that
were seen earlier when making web requests. In this scenario, sometimes I want to try the
mobile app against my local development version of the API. To do this, I have a rewrite that
simply routes anything for http://api.joind.in to http://api.joindin.local. This is in the hosts
file on my machine, so it knows that domain is on the local host. Here is the rewrite rule in
Charles:
When I tick and untick the joindin-api-dev box, I interrupt trac to the live API, and instead
send it to my local version of the API, which contains sample data and possibly local
modifications. This is such a powerful feature when doing mobile development, because the
data sources can be swapped without any need to restart the app, and certainly without
changing or rebuilding it. This tactic is useful both when the app cant be changed, and also
when its simpler to intercept its trac for testing.
As we already mentioned, Charles then intercepts the trac, using the remote sites correct
SSL certificate for the connection between there and Charles, then an untrusted one between
Charles and the client. This means that when you enable this in Charles, your browser will tell
you that there isnt a valid SSL certificate for the remote site.
Confirm the security exception and you can now proceed as normal with all the features
mentioned in the earlier sections of this post. Charles isnt the only tool to oer this
functionality, but its one of the easiest to get up and running with. When testing or debugging
for SSL setups, this is a very valuable addition to the toolbox, and one that I hope youll find
useful moving forward.
Other good products are available and you may also choose to make use of these. We also use
Curl for being able to make many dierent kinds of web requests and to easily share them by
pasting the commands into the bug trackers. Another alternative if you only need to inspect
(non-SSL) trac is Wireshark, as we mentioned earlier in the article. Both Curl and Wireshark
are free, multiplatform tools.
Charles tag line web debugging proxy is pretty accurate, making it indispensable in many
situations. If youve got a Charles tip to share, or want to tell us how you make use of the
techniques shown here, please do leave us a comment, wed love to hear from you!
+1144
Share
Tweet
Tags: browser, charles, curl, debugging, development, http, mobile, techniques, tools,
wireshark
by Lorna Mitchell/5 Comments
Related Posts
Profiling PHP Applications with XHGui
Tips for Developing Apps with PhoneGap
Building a Continuous Integration Server for PHP with Hudson
DPCRadio: The Art of Scalability
Home
About
Events
Open Source
Vote for a Topic
Write for Techportal
Follow us on Twitter
RSS
Search
Search site
Popular Posts
Testing Javascript: Get Started with Jasmine (1276)
Conference report: nodeconf ONE-SHOT London (1207)
Conference roundup: PHPNW 2014 (1196)
Manipulating HTTP with Charles Proxy (1144)
RESTFest 2014 and Women in Tech (1141)
Recent Posts
Testing Javascript: Get Started with Jasmine
Conference roundup: PHPNW 2014
RESTFest 2014 and Women in Tech
Tags
agile apc
architecture atk bdd behat best practice caching challenge code competition
conference
database derick rethans development DPC dpc10 dpc11 dutch php conference frontend github
http ibuildings Javascript keynote
symfony testing tipstricks tools unit testing xhprof zend zend framework
Archive
2014
2013
2012
2011
2010
2009
2008
2007
2006
Session Digital is the leading Magento Enterprise partner in the UK, specialising in
providing eCommerce solutions to companies using Magento Enterprise.
info@sessiondigital.com