What makes conditional GETs "conditional" if the resource is obtained in the initial request?

Question

Breaking down what makes a conditional GET:

In RFC 2616 it states that the GET method change to a "conditional GET" if the request message includes an If-* (If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range) header field.

It then states:

A conditional GET method requests that the entity be transferred ONLY under the circumstances described by the conditional header field(s).

From my understanding this is saying it will only return the data being requested if the condition is met with the "If-*" in any new subsequent requests. For example, if a GET request returns a response with a Etag header then the next request must include the If-None-Match with the ETag value to transfer the client back the requested resource.

However, If a client has to send an initial request before getting the returned "ETag" header (to return with If-None-Match) then they already have the requested resource. Thus, any future requests that return the If-None-Match header with the ETag value only dictate the return of the requested value, returning 200 OK (if the client does not return the If-None-Matchand ETag value from initial request) or 304 Not Modified (if they do), where this helps the client and server by caching the resource.

My Question:

Why does it state the entity (the resource from a request) will "be transferred ONLY" if the If-* condition is met (like in my example where the client returns the ETag value with anIf-None-Match in order to cache the requested resource) if the resource or "entity" is being returned with or without a "If-*" being returned? It doesn't return a resource "only under the circumstances described by the conditional header" because it returns the resource despiteless returning 200 OK or 304 Not Modified depending on if a "If-*" header is returned. What am I misunderstanding about this?

Full conditional GET reference from RFC 2616:

The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.

Answer 1

First of all, please note that RFC 2616 is obsolete, and you should refer instead to RFC 7232.

It's hard to see what exactly is confusing you. So let me just illustrate with examples instead.

Scenario 1

Client A: I need http://example.com/foo/bar.

GET /foo/bar HTTP/1.1
Host: example.com

Server: Here you go.

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 12
ETag: "2ac07d4"

Hello world!

(some time passes)

Client A: I need http://example.com/foo/bar again. But I already have the "2ac07d4" version in my cache. Maybe that will do?

GET /foo/bar HTTP/1.1
Host: example.com
If-None-Match: "2ac07d4"

Server: Yeah, "2ac07d4" is fine. Just take it from your cache, I'm not sending it to you.

HTTP/1.1 304 Not Modified

Scenario 2

Client A: I need http://example.com/foo/bar.

GET /foo/bar HTTP/1.1
Host: example.com

Server: Here you go.

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 12
ETag: "2ac07d4"

Hello world!

(some time passes)

Client B: I want to upload a new version of http://example.com/foo/bar.

PUT /foo/bar HTTP/1.1
Content-Type: text/plain
Content-Length: 17

Hello dear world!

Server: This looks good, I'm saving it. I will call this version "f6049b9".

HTTP/1.1 204 No Content
ETag: "f6049b9"

(more time passes)

Client A: I need http://example.com/foo/bar again. But I already have the "2ac07d4" version in my cache. Maybe that will do?

GET /foo/bar HTTP/1.1
Host: example.com
If-None-Match: "2ac07d4"

Server: I'm sorry, but "2ac07d4" is out of date. We have a new version now, it's called "f6049b9". Here, let me send it to you.

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 17
ETag: "f6049b9"

Hello dear world!

Analysis

A conditional GET method requests that the entity be transferred ONLY under the circumstances described by the conditional header field(s).

Consider Client A's second request (in both scenarios).

The conditional header field is: If-None-Match: "2ac07d4".

The circumstances described by it are: "a selected representation of the resource does not match entity-tag "2ac07d4"".

Scenario 1: the circumstances do not hold, because the selected representation of the resource (the one containing Hello world!) does indeed match entity-tag "2ac07d4". Therefore, in accordance with the protocol, the server does not transfer the entity in its response.

Scenario 2: the circumstances do hold: the selected representation of the resource (the one containing Hello dear world!) doesn't match entity-tag "2ac07d4" (it matches "f6049b9" instead). Therefore, in accordance with the protocol, the server does transfer the entity in its response.

How does the server come up with these "2ac07d4" and "f6049b9", anyway? Of course, this depends on the application, but one straightforward way to do it is to compute a hash (such as SHA-1) of the entity body--a value that changes dramatically when even small changes are introduced.