rewrite and 304

[lucy24]

OK, I'm overlooking something embarrassingly obvious again.

What is it about a rewrite that prevents the server from sending a 304?

Like this. Take your basic invisible one-pixel administrative dot. In this case dot1.gif, dot2.gif et cetera for the different pages. If people come back to the same page, they show up in the logs as a 304 for the dot. As expected.

Then I need to add some more dots to track more stuff, and at this point I whap myself upside the head and realize that I don't need a folder full of individual, literal dots. All I need is a conditionless rule

RewriteRule /dot\d\d\.gif {local path}/onedot.gif [L]

The 304s disappear. Visit three times in a row and you're served with three consecutive 200s-- unless you're getting one of the original, non-rewritten single-digit dots. (Didn't bother to delete them.)

I tried it myself, asking for nonexistent dots by name. (Detour here for further head-whapping before I realize that I have to refresh the browser window, or else it will just grab one from the cache and never even show up in the logs.) Nothing but 200.

I assume the same thing happens with existing rewrites like the ones for hotlinks. Just never paid attention there.

What's going on? :(

....

Uhm. Yes. I did only just realize that the leading / has no business there. But it doesn't seem to have fazed the rule at all. And deleting it doesn't change the behavior.

[coopster]

What do your request and response headers look like when you first retrieve the image? I mean, do you see the If-Modified-Since header being sent?

[g1smd]

The server deals with the browser in terms of responses to URL requests, not in terms of files retrieved from the filesystem.

[lucy24]

Yeah, that's why I'm baffled. The rewrite shouldn't have any effect-- but somehow it does.

:: detour to investigate ::

Curiouser and curiouser. In Firefox with Live Headers it says 304-- along with a bunch of stuff that's basically Hungarian to me. But in the logs, that identical request is recorded as a 200. And just to remove all doubt, the log entries are bracketed by robots receiving 304s ;)

[lucy24]

Bumping this because there have been a couple of recent questions about caching so naturally it turned my mind to the 304.

New question: Who sends the header? It can't be the requested file; it doesn't exist. And it can't be the real file; your browser isn't supposed to know it exists. So where does the "modified" information come from?

I went and had a look at the least revolting of my currently active hotlinkers. Here, the image request is rewritten to a wonderfully garish png that says "No Hotlinks". Apparently the site owner never looks at his own page; it's pretty hard to overlook.

First time around:

HTTP/1.1 200 OK
...
Vary: Referer
Last-Modified: Thu, 21 Oct 2010 20:32:26 GMT

(this information is valid for the "No Hotlinks" png; the real file is older)

Etag: "b9a6086-9ad-493266c8c0a80"

(is this what The Sources mean when they keep blathering about "fingerprints"? where does the number come from? did Apache just make it up on its own initiative?)

Accept-Ranges: bytes
Content-Length: 2477

(the exact size of the "No Hotlinks" png; the real file is a few bytes bigger)

Logs say

200 2770

(where did the extra 293 bytes come from?)

And repeat (twice, with same results).

GET...
...
If-None-Match: "b9a6086-9ad-493266c8c0a80"
Cache-Control: max-age=0

HTTP/1.1 304 Not Modified
...
Etag: "b9a6086-9ad-493266c8c0a80"
Vary: Referer

Logs say:

200 188

Say what now? What is it that's 188 bytes? How come it's getting logged as a 200 when the headers said loud and clear 304?