curl -i and curl -I returning different results

Question

My understanding was that curl -i and curl -I would return virtually the same results except that curl -i would return the standard output along with the header and curl -I would only return the header -- the header of both being the same. We've been doing some gzip and un-gzipped testing with Varnish and stumbled upon the oddity that curl -i shows X-Cache: HIT but curl -I returns X-Cache: MISS! How this is possible, I am unsure and that is precisely my question in this post.

Here are some more details that may or may not make a difference:

1. The URL is usually SSL enforced (https) but both HTTP and HTTPS have been tested to receive same results
2. The results are consistent
3. Is Varnish Running site says "Yes! Sort of"

Solution 1

curl sends different HTTP requests to the server (or Varnish in this case) when you use the -I option. Normally, curl will send a GET request, but when you specify -I, it sends HEAD instead (essentially telling the server to just send the header, not the actual content). I'm not particularly familiar with Varnish, but it appears to normally cache both GET and HEAD requests -- but in your case it might be configured to do something different, or the backend server may be triggering a difference... In any case, I'm pretty sure it's GET vs. HEAD that's making the cache respond differently with -i vs. -I.

Solution 2

did you check in different orders?

see: http://anothersysadmin.wordpress.com/2008/04/22/x-cache-and-x-cache-lookup-headers-explained/ for some details on X-Cache

Comments

[Tejas Manohar]

@jww Seriously? I happen to disagree. This question deals with Varnish caching and specifications of the cURL UNIX command... These topics are "software tools commonly used by programmers" and very common software development techniques among programmers. Many questions on these topics have been discussed and promoted. Super User's topics are "computer hardware, computer software, or personal and home computer networking".

[Tejas Manohar]

tested from different locations (office and home), different machines (co-workers), different orders, and reset local cache. results are seemingly consistent with no extraneous results.

[Tejas Manohar]

Nevermind, this was exactly it :) except that Rails 3 doesn't deal with HEAD by default as it isn't in RESTful by default, no need to route these to GET requests and waste an object in cache