[squid-users] storeurl_rewriter and "URL mismatch" log entries

Hello,

I have a squid application where a storeurl_rewriter program is needed
to normalize incoming fetch urls into the same url. I am running
squid-2.7_9, and have a storeurl_rewriter program that gets launched at
squid startup. In my config file, I set storeurl_rewrite_children to
100, and only allow http requests to come through (using the
storeurl_access allow proto HTTP setting, so any
cache_object://localhost requests will be ignored).

The problem I am having is I keep getting cache.log entries that look
like "storeClientReadHeader: URL mismatch", comparing the incoming fetch
url with my normalized url. I am getting thousands of these errors an
hour. I was sure to clear out the squid cache as I launched my new
storeurl_rewriter program, so I don't understand how the cache has any
of the original fetch urls in it at all to be causing this URL mismatch.
I was getting warnings about not enough storeurl_rewriter programs
running, which was when I bumped it up to 100. I was also having an
issue where logs showed that when the cache_object://localhost requests
came through, my program shut down, which was why I added the access
setting. I don't see either of these warnings in the logs anymore, yet
still see tons of URL mismatch errors.

Does anyone have any ideas on this?

Just to clarify a bit more...suppose a fetch url looks like
http://www.fetchme.com/123456, but it should then go through my
storeurl_rewriter program where it will be turned into
http://www.normalized.com/123456, and this is what should be used to
fetch and then cache. My assumption is that every fetch request goes
through storeurl_rewriter, so how is it that I would be seeing so many
log entries like "storeClientReadHeader: URL mismatch
{http://www.normalized.com/123456} != {http://www.fetchme.com/123456}?
Is there some case where a fetch request does not go through
storeurl_rewriter? If it was busy, I think I would be seeing a log
warning saying so, which I am not since I bumped children to 100.

Thanks so much,

Kathleen
Received on Wed Nov 18 2009 - 00:15:31 MST