geschätzte Lesezeit: 2 min

You will find here different ways to upgrade your wallabag:

• from 2.3.x to 2.4.x
• from 2.3.x to 2.3.y
• from 2.2.x to 2.3.x
• from 2.x.y to 2.3.x
• from 1.x to 2.x

Upgrading from 2.3.x to 2.4.x

Same steps as for upgrading from 2.2.x to 2.3.x.

For shared hosting

PHP version compatibility have changed, check the release notes for details.

Apply the general steps for upgrades on the shared hosting with the following modifications :

Use these data queries for the database upgrade to 2.4.

Four parameters were created and MUST be added to your app/config/parameters.yml file : mailer_port, mailer_encryption, mailer_auth_mode and sentry_dsn

Do not forget to run bin/console cache:clear --env=prod in the wallabag directory afterwards

Upgrading from 2.3.x to 2.3.y

make update

That's all.

If you got an error with Not a git repository, it means you didn't install wallabag using git but rather using an archive. Follow steps for the shared hosting then.

Upgrading from 2.2.x to 2.3.x

Upgrade on a dedicated web server

make update

Upgrade on a shared hosting

1. Backup your app/config/parameters.yml file.

2. Download the last release of wallabag:

    wget https://wllbg.org/latest-v2-package && tar xvf latest-v2-package
   

   You will find the md5 hash of the latest package on our website.

3. Extract the archive in your wallabag folder and replace app/config/parameters.yml with yours.

4. Please check that your app/config/parameters.yml contains all the parameters as they are all mandatory. You can find here a documentation about parameters.
5. I you have modified the app/config/parameters.yml file, run bin/console cache:clear --env=prod afterwards in the wallabag directory. A warning will appear if a parameter was forgotten.
6. If you use SQLite, you must also copy your data/ folder inside the new installation.
7. Empty var/cache folder.
8. You must run some SQL queries to upgrade your database. We assume that the table prefix is wallabag_. Don't forget to backup your database before migrating.
9. You may encounter issues with indexes names: if so, please change queries with the correct index name.
10. You can find all the queries here.

Upgrading from 2.x.y to 2.3.x

If your wallabag instance is < 2.2.0, there is no automatic script. You need to:

• export your data
• install wallabag 2.3.x (read the installation documentation)
• import data in this fresh installation (read the import documentation )

From wallabag 1.x

There is no automatic script to update from wallabag 1.x to wallabag 2.x. You need to:

• export your data
• install wallabag 2.x (read the installation documentation)
• import data in this fresh installation (read the import documentation )

geschätzte Lesezeit: 5 min

Note your current version#

If anything goes wrong, it's important for us to know which version you're upgrading from. The current version is present in the shaarli_version.php file.

Backup your data#

Shaarli stores all user data and configuration under the data directory. Backup this repository before upgrading Shaarli. You will need to restore it after the following upgrade steps.

sudo cp -r /var/www/shaarli.mydomain.org/data ~/shaarli-data-backup

If you installed Shaarli from a release ZIP archive:

# Download the archive to the server, and extract it
cd ~
wget https://github.com/shaarli/Shaarli/releases/download/v0.X.Y/shaarli-v0.X.Y-full.zip
unzip shaarli-v0.X.Y-full.zip
# overwrite your Shaarli installation with the new release **All data will be lost, see _Backup your data_ above.**
sudo rsync -avP --delete Shaarli/ /var/www/shaarli.mydomain.org/
# restore file permissions as described on the installation page
sudo chown -R root:www-data /var/www/shaarli.mydomain.org
sudo chmod -R g+rX /var/www/shaarli.mydomain.org
sudo chmod -R g+rwX /var/www/shaarli.mydomain.org/{cache/,data/,pagecache/,tmp/}
# restore backups of the data directory
sudo cp -r ~/shaarli-data-backup/* /var/www/shaarli.mydomain.org/data/
# If you use gettext mode for translations (not the default), reload your web server.
sudo systemctl restart apache2
sudo systemctl restart nginx

If you don't have shell access (eg. on shared hosting), backup the shaarli data directory, download the ZIP archive locally, extract it, upload it to the server using file transfer, and restore the data directory backup.

Access your fresh Shaarli installation from a web browser; the configuration and data store will then be automatically updated, and new settings added to data/config.json.php (see Shaarli configuration for more details).

Upgrading from Git#

If you have installed Shaarli from sources:

# pull new changes from your local clone
cd /var/www/shaarli.mydomain.org/
sudo git pull
# update PHP dependencies (Shaarli >= v0.8)
sudo composer install --no-dev
# update translations (Shaarli >= v0.9.2)
sudo make translate
# If you use translations in gettext mode (not the default), reload your web server.
sudo systemctl reload apache
sudo systemctl reload nginx
# update front-end dependencies (Shaarli >= v0.10.0)
sudo make build_frontend
# restore file permissions as described on the installation page
sudo chown -R root:www-data /var/www/shaarli.mydomain.org
sudo chmod -R g+rX /var/www/shaarli.mydomain.org
sudo chmod -R g+rwX /var/www/shaarli.mydomain.org/{cache/,data/,pagecache/,tmp/}

Access your fresh Shaarli installation from a web browser; the configuration and data store will then be automatically updated, and new settings added to data/config.json.php (see Shaarli configuration for more details).

---

Migrating and upgrading from Sebsauvage's repository#

If you have installed Shaarli from Sebsauvage's original Git repository, you can use Git remotes to update your working copy.

The following guide assumes that:

• you have a basic knowledge of Git branching and remote repositories
• the default remote is named origin and points to Sebsauvage's repository
• the current branch is master
  • if you have personal branches containing customizations, you will need to rebase them after the upgrade; beware though, a lot of changes have been made since the community fork has been created, so things are very likely to break!
• the working copy is clean:
  • no versioned file has been locally modified
  • no untracked files are present

Step 0: show repository information#

$ cd /path/to/shaarli
$ git remote -v
origin  https://github.com/sebsauvage/Shaarli (fetch)
origin  https://github.com/sebsauvage/Shaarli (push)
$ git branch -vv
* master 029f75f [origin/master] Update README.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

Step 1: update Git remotes#

$ git remote rename origin sebsauvage
$ git remote -v
sebsauvage  https://github.com/sebsauvage/Shaarli (fetch)
sebsauvage  https://github.com/sebsauvage/Shaarli (push)
$ git remote add origin https://github.com/shaarli/Shaarli
$ git fetch origin
remote: Counting objects: 3015, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 3015 (delta 446), reused 457 (delta 446), pack-reused 2550
Receiving objects: 100% (3015/3015), 2.59 MiB | 918.00 KiB/s, done.
Resolving deltas: 100% (1899/1899), completed with 48 local objects.
From https://github.com/shaarli/Shaarli
 * [new branch]      master     -> origin/master
 * [new branch]      stable     -> origin/stable
[...]
 * [new tag]         v0.6.4     -> v0.6.4
 * [new tag]         v0.7.0     -> v0.7.0

Step 2: use the stable community branch#

$ git checkout origin/stable -b stable
Branch stable set up to track remote branch stable from origin.
Switched to a new branch 'stable'
$ git branch -vv
  master 029f75f [sebsauvage/master] Update README.md
* stable 890afc3 [origin/stable] Merge pull request #509 from ArthurHoaro/v0.6.5

Shaarli >= v0.8.x: install/update third-party PHP dependencies using Composer:

$ composer install --no-dev
Loading composer repositories with package information
Updating dependencies
  - Installing shaarli/netscape-bookmark-parser (v1.0.1)
    Downloading: 100%

Shaarli >= v0.9.2 supports translations:

$ make translate

If you use translations in gettext mode, reload your web server.

Shaarli >= v0.10.0 manages its front-end dependencies with nodejs. You need to install yarn:

$ make build_frontend

Optionally, you can delete information related to the legacy version:

$ git branch -D master
Deleted branch master (was 029f75f).
$ git remote remove sebsauvage
$ git remote -v
origin  https://github.com/shaarli/Shaarli (fetch)
origin  https://github.com/shaarli/Shaarli (push)
$ git gc
Counting objects: 3317, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (1237/1237), done.
Writing objects: 100% (3317/3317), done.
Total 3317 (delta 2050), reused 3301 (delta 2034)to

Step 3: configuration#

After migrating, access your fresh Shaarli installation from a web browser; the configuration will then be automatically updated, and new settings added to data/config.json.php (see Shaarli configuration for more details).

Troubleshooting#

If the solutions provided here don't work, see Troubleshooting and/or open an issue specifying which version you're upgrading from and to.

geschätzte Lesezeit: 14 min

Table of Contents

1. Display Advertisements 
2. Find Sponsors 
3. Increase the Price 
4. Make Your Product Exclusive/Personal 
5. Make Updates Regularly 
6. Apply Separate Licenses to Certain Parts 
7. Sell Service, Not Product 
8. Be Beneficial 
9. Offer Private Courses 
10. Offer Price to Publish 
11. Multi Licensing 

Stop trying to be rich by selling GPL licensed products!

This is a reminder to all extension and layout makers out there, that, to sell extensions and layouts built for Mecha is possible, but preventing your clients from sharing your paid extensions and layouts for free or for another fee to the public is impossible, even after your client pays for it. This is due to the binding nature of the GPL license. Derivative works and all works that depend on Mecha’s functionality must be licensed under the same terms, which eventually will limit your authority in taking the abundant financial benefits of the extensions and layouts you want to sell.

Even if you had to re-create a new version of Mecha separately in order to make it commercially viable, this will not allow you to change the initial license anyway, because technically you’re only modifying Mecha, not creating something new. And therefore this will still prevent you from restricting people to redistribute the products they have purchased legally.

As written in the preamble of the license, the GNU General Public License is a free, copyleft license for software and other kinds of works. General Public License is designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs.

Extensions and layouts, even if they have been made separately, will still be considered derivative works as long as they interact directly with the features and functions of Mecha. As seen in this FAQ section about modules:

If I add a module to a GPL-covered program, do I have to use the GPL as the license for my module?

The GPL says that the whole combined program has to be released under the GPL. So your module has to be available for use under the GPL.

But you can give additional permission for the use of your code. You can, if you wish, release your module under a license which is more lax than the GPL but compatible with the GPL.

The GPL license clearly aims for the public benefit. For those of you who want to make money from products that you give a GPL license ¹, you may feel less enthusiastic about the selling due to the public’s freedom to modify and redistribute your products. Yes, you can sell them as much as you want, but you can’t stop people from reselling them or giving them away for free. For the GPL license, those activities are still considered legal as long as they keep the license document on the distributed products. The GPL license does not restrict what people do in software, it just stops them from restricting others.

See this FAQ section about whether a paid software makers can restrict their clients from redistributing the purchased software for free or for a fee:

If I distribute GPL-ed software for a fee, am I required to also make it available to the public without a charge?

No. However, if someone pays your fee and gets a copy, the GPL gives them the freedom to release it to the public, with or without a fee. For example, someone could pay your fee, and then put her copy on a web site for the general public.

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. This can usually be done in several ways:

1. By asking a client to pay for a software to be used at a restricted time and/or scope. For example, a client may use your software on one personal computer only, for a year. To use it on five personal computer and/or to use it for the next five years, he/she has to pay extra.
2. By limiting the intended use of the software. For example, a client may only use your theme for non-commercial purposes. Or, a client may only use your theme on websites that do not contain advertisements. To remove such restriction, clients must incur extra costs.
3. By preventing clients from reselling your software. By reselling your software, clients may need to sign a certain agreement. For example, to do a profit sharing on every sale they make.
4. By forcing the placement of attribution links (or any form of attribution including logos and watermarks) on certain parts of your product that are used by your clients. To remove the attribution, clients must incur extra costs.
5. By obfuscating the code in your software, so that the software can only be used but cannot be further developed. To be able to develop or modify the software, clients have to pay more to get the source code.

The bad news is, all of the business models above have violated the GPL license, as they have stopped the public’s freedom to share, learn and develop, which is the essence of the GPL license.

It doesn’t mean that the product has become illegal, it’s just that the product has fallen out of the spirit of “Free Software”. It also shows that the makers of these products lack education about the principles of “Free Software”, and of course about the GPL license itself.

Thesis has experienced it through the case between Chris Pearson and Matt Mullenweg, and I hope you don’t repeat it.

“Free software” means software that respects users’ freedom and community. Roughly, it means that the users have the freedom to run, copy, distribute, study, change and improve the software. Thus, “free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech”, not as in “free beer”. We sometimes call it “libre software”, borrowing the French or Spanish word for “free” as in freedom, to show we do not mean the software is gratis.

You may have paid money to get copies of a free program, or you may have obtained copies at no charge. But regardless of how you got your copies, you always have the freedom to copy and change the software, even to sell copies ².

There are several ways to make money from your own products and still contribute to the free software community. This requires you to think out of the box. Some of them explain very clearly that the best way to make money from open-source softwares is to not focus on the products, but to focus on something else.

Display Advertisements 

This is the most classic way. You can get income by displaying third party advertisements on the software you distribute. The disadvantage of this method is that your users can modify your software to remove the advertisement code from your software, and this is not illegal.

Ubuntu has done that in the past. By displaying an Amazon application icon on the dash panel, as well as directing topic/application search queries to get search results from the Amazon store.

Technically, you can add some kind of disabled settings for your non-savvy users to remove advertisements on your software via graphical user interface, which can then become active after your users pay extra fees in exchange for the revenue that would otherwise be earned from the advertisers. As long as you don’t sue users who are able to remove its restrictions from the source code, this should not violate the “Free Software” principle.

One other way to get money from advertisers is to be affiliated with other companies that are willing to sponsor your software. For example, as a Mecha developer, I might need a sponsor in the form of a virtual private server, and if a company is willing to sponsor me, then I can display their logo and company link on this website, or in the README.md file of the main repository, and recommend people to use their services.

Increase the Price 

By charging a high price for your software, your clients are less likely to give it away for free, but they may try to sell it at a lower price many times until their investment returns. You need to find clients who don’t have the potential to resell your software.

Make Your Product Exclusive/Personal 

This is still a form of selling services. Let’s say, you develop a layout framework for Mecha with complex features available under the GPL license (it has to be). You provide a paid service to adjust the design of the layout according to client’s requests. Whether by customizing the color pallete and the typography designs, by creating custom website logo, or by filling the contents until the website is ready for production.

Of course this will still allow your clients to distribute your custom designs for free or even for a fee. However, since you have made certain customizations according to the client’s personality, the possibility for your clients to share the customized design to the public will be very low. They don’t want their design to be used by others, aren’t they? Here, you have to be smart enough to bring the client’s emotions into the design.

The GPL license only authorizes people to use, distribute and modify the work without conditions, but does not oblige them to do so.

This will keep your paid products worth buying. Previous buyers may have distributed your purchased product to many places, but people will not get updates from products that are not officially distributed, except by purchasing it directly to the developer.

Apply Separate Licenses to Certain Parts 

You can apply separate licenses on parts that are independent of the core system functionality. These parts are usually in the form of static assets that aim to be presented as-is to the viewer. There are some parts that have the potential to be licensed separately:

1. Your CSS and JavaScript files. If you make the CSS and JavaScript code from scratch without relying on CSS and JavaScript code from others ³, then you can take the advantage to prevent people from distributing your product as a single entity. Technically, they could actually just distribute the PHP files, but that wouldn’t make the product useful without the CSS and JavaScript files. Yes, people will probably look for a live version of the product and then they will download the CSS and JavaScript files from there. But yeah, don’t think too much about it either. There will be many ways for people to get things off the web anyway.
2. Your fonts, icons, logos, and all binary files that can be served directly without having to call functions from the core system to make them to work. By including files that you own the copyright into your product, then you can take the advantage to prevent people from distributing your product as a single entity.
3. Your design system. I’ve never heard of anyone copyrighting the system. But this might be worth a try.

This is the reason why Mecha doesn’t have any base CSS and JavaScript files to be required, just like in any other CMS. I don’t want the GPL “virus” to spread further until you don’t have control over the CSS and JavaScript code (the design) so that there’s no more you can limit your clients from, who can use your product for any purposes, even to resell your product.

Sell Service, Not Product 

TinyMCE and CKEditor have done this kind of thing. They focus not on the product, but on the benefits that their product gives to the users. And they use the opportunity to sell online storage and personal support services.

Another example comes from Red Hat. Red Hat doesn’t sell software. Red Hat sells service/support subscriptions. You can download the software for free.

WordPress runs WordPress.com, providing free web hosting powered by WordPress content management system with various limitation. With the paid version, you can get rid of those limitations such as to remove advertisement from WordPress.com or to allow you to earn revenue from your own advertisement platform.

This restriction applies because you are using the hosting service, not because you are using the WordPress. You can download WordPress software for free and use it on another hosting service to get rid of the limitations. But you will probably need some skills to make it work perfectly.

Be Beneficial 

Solve companies problems and give them various benefits through your project. Benefits don’t have to be in the form of money. Sometimes, time and expertise can also be included. They’re already busy with clients. They don’t have time to build and maintain their own softwares.

If the company has been interested in you until it finally depends on your project, then it is not impossible that they will become financial contributor to you to ensure the development of your project. And since you don’t have any employment contract with them and your project is open-source, it’s likely not only one company that will become financial contributor to your project. Any companies that depends on your project can step in and provide support.

CodeMirror is a JavaScript-based software that has been used and sponsored by many companies. This is a real example to show that GPL license does not prevent you from making money out of your free softwares.

Vue is MIT licensed, in which is a permissive license that allows others to make modifications even to the point of distributing it as closed-source software, but still able to grow through sponsors.

Offer Private Courses 

Create online courses that can only be accessed by members. To become a member, people have to pay certain fee. It can be paid once or by subscription, depending on your business model. Please note that software documentation must be free.

Offer Price to Publish 

This is the business model that I want to do, and I feel it suits me best. I currently don’t have the resources to be able to securely store client data. I don’t have an office, and currently do all this just for fun, to convey ideas through products. I don’t even know how to communicate with clients the way professionals communicate with clients who spend money on them.

The GPL license only authorizes people to use, distribute and modify the work without conditions, but does not oblige them to do so. This means that I may create an extension or layout privately, not for the public. From there, I can then show some teasers on my store page by providing documentation and some screen captures of the extensions and layouts that require funds to be released to the public, to make potential clients want them available for download.

I will probably set a fixed price on the product page, but with an explanation that the price to be paid is a contribution of funds that will be accumulated. Until the funding target is met, the product will be released as free software.

In return, I will include the link and name of the buyers (financial contributors) in the README.md and about.page files which will last forever, and will follow wherever the product will be distributed.

Multi-Licensing 

Multi-licensing is commonly done to support free software business models in a commercial environment. In this scenario, one option is a proprietary software license, which allows the possibility of creating proprietary applications derived from it, while the other license is a copyleft free software/open-source license, thus requiring any derived work to be released under the same license. The copyright holder of the software then typically provides the free version of the software at little or no cost, and profits by selling proprietary licenses to commercial operations looking to incorporate the software into their own business ⁴.

Metafizzy uses this business model to profit from companies that depend on its products.

Until Mecha is able and proven to be profitable for companies, I will continue to use the GPL license only, and will continue to use the license if there is no point in granting other licenses to it.

I also need to consider people involved with the development. Changing an open-source project license would require me to get permission from people who have contributed to the code.

geschätzte Lesezeit: < 1 min

A monumental deal in disc golf media

May 2, 2023 by Josh Mansfield and Charlie Eisenhood in Podcast with 0 comments

Charlie Eisenhood and Josh Mansfield welcome in DGPT CEO Jeff Spring and JomezPro founder Jonathan Gomez to discuss the Pro Tour’s acquisition of Jomez in a landmark media consolidation. Then they provide their own thoughts on the deal before hitting Jonesboro Open #PurseWatch, giving their hole 18 grades, and more.

The Upshot: DGPT Acquires JomezPro

You can contact Charlie and Josh at upshot@ultiworld.com.

Note: You can follow Ultiworld and The Upshot on Spreaker. The podcast is also available on iTunes, Spotify, Stitcher, iHeartRadio, Deezer, RSS, Google Play, and your other favorite podcasting apps.

TAGGED: DGPT Elite Series, Disc Golf Network, Disc Golf Pro Tour, Jeff Spring, Jomez Productions, JomezPro, Jonathan Gomez, Presented By Pound Disc Golf, The Upshot

EVENTS: 2023 Jonesboro Open

More from Ultiworld

geschätzte Lesezeit: 5 min

November 16, 2008

There are different kinds of HTTP caches that are useful for different kinds of things. I want to talk about gateway caches – or, “reverse proxy caches” – and consider their effects on modern, dynamic web application design.

Draw an imaginary vertical line, situated between Alice and Cache, from the very top of the diagram to the very bottom. That line is your public, internet facing interface. In other words, everything from Cache back is “your site” as far as Alice is concerned.

Alice is actually Alice’s web browser, or perhaps some other kind of HTTP user-agent. There’s also Bob and Carol. Gateway caches are primarily interesting when you consider their effects across multiple clients.

Cache is an HTTP gateway cache, like Varnish, Squid in reverse proxy mode, Django’s cache framework, or my personal favorite: rack-cache. In theory, this could also be a CDN, like Akamai.

And that brings us to Backend, a dynamic web application built with only the most modern and sophisticated web framework. Interpreted language, convenient routing, an ORM, slick template language, and various other crap – all adding up to amazing developer productivity. In other words, it’s horribly slow and bloated… and awesome! There’s probably many of these processes, possibly running on multiple machines.

(One would typically have a separate web server -- like Nginx, Apache or lighttpd -- and maybe a load balancer sitting in here as well but that's largely irrelevant to this discussion and has been omitted from the diagrams.)

Expiration

Most people understand the expiration model well enough. You specify how long a response should be considered “fresh” by including either or both of the Cache-Control: max-age=N or Expires headers. Caches that understand expiration will not make the same request until the cached version reaches its expiration time and becomes “stale”.

A gateway cache dramatically increases the benefits of providing expiration information in dynamically generated responses. To illustrate, let’s suppose Alice requests a welcome page:

Since the cache has no previous knowledge of the welcome page, it forwards the request to the backend. The backend generates the response, including a Cache-Control header that indicates the response should be considered fresh for ten minutes. The cache then shoots the response back to Alice while storing a copy for itself.

Thirty seconds later, Bob comes along and requests the same welcome page:

The cache recognizes the request, pulls up the stored response, sees that it’s still fresh, and sends the cached response back to Bob, ignoring the backend entirely.

Note that we’ve experienced no significant bandwidth savings here – the entire response was delivered to both Alice and Bob. We see savings in CPU usage, database round trips, and the various other resources required to generate the response at the backend.

Validation

Expiration is ideal when you can get away with it. Unfortunately, there are many situations where it doesn’t make sense, and this is especially true for heavily dynamic web apps where changes in resource state can occur frequently and unpredictably. The validation model is designed to support these cases.

Again, we’ll suppose Alice makes the initial request for the welcome page:

The Last-Modified and ETag header values are called “cache validators” because they can be used by the cache on subsequent requests to validate the freshness of the stored response without requiring the backend to generate or transmit the response body. You don’t need both validators – either one will do, though both have pros and cons, the details of which are outside the scope of this document.

So Bob comes along at some point after Alice and requests the welcome page:

The cache sees that it has a copy of the welcome page but can’t be sure of its freshness so it needs to pass the request to the backend. But, before doing so, the cache adds the If-Modified-Since and If-None-Match headers to the request, setting them to the original response’s Last-Modified and ETag values, respectively. These headers make the request conditional. Once the backend receives the request, it generates the current cache validators, checks them against the values provided in the request, and immediately shoots back a 304 Not Modified response without generating the response body. The cache, having validated the freshness of its copy, is now free to respond to Bob.

This requires a round-trip with the backend, but if the backend generates cache validators up front and in an efficient manner, it can avoid generating the response body. This can be extremely significant. A backend that takes advantage of validation need not generate the same response twice.

Combining Expiration and Validation

The expiration and validation models form the basic foundation of HTTP caching. A response may include expiration information, validation information, both, or neither. So far we’ve seen what each looks like independently. It’s also worth looking at how things work when they’re combined.

Suppose, again, that Alice makes the initial request:

The backend specifies that the response should be considered fresh for sixty seconds and also includes the Last-Modified cache validator.

Bob comes along thirty seconds later. Since the response is still fresh, validation is not required; he’s served directly from cache:

But then Carol makes the same request, thirty seconds after Bob:

The cache relies on expiration if at all possible before falling back on validation. Note also that the 304 Not Modified response includes updated expiration information, so the cache knows that it has another sixty seconds before it needs to perform another validation request.

More

The basic mechanisms shown here form the conceptual foundation of caching in HTTP – not to mention the Cache architectural constraint as defined by REST. There’s more to it, of course: a cache’s behavior can be further constrained with additional Cache-Control directives, and the Vary header narrows a response’s cache suitability based on headers of subsequent requests. For a more thorough look at HTTP caching, I suggest Mark Nottingham’s excellent Caching Tutorial for Web Authors and Webmasters. Paul James’s HTTP Caching is also quite good and bit shorter. And, of course, the relevant sections of RFC 2616 are highly recommended.

(Oh, and the diagrams were made using websequencediagrams.com, a very simple, text-based sequence diagram generating web service thingy.)