Recent versions of Squid support the HTTP/1.1 Vary header. This is good news if your backend server uses content negotiation. It might, for example, send different responses depending on which web browser makes the request (e.g., the User-Agent header), or based on the user's language preferences (e.g., the Accept-Language header).
When the response for a URI varies on some aspect of the request, the origin (backend) server includes a Vary header. This header contains the list of request headers used to select the variant. These are the selecting headers. When Squid receives a response with a Vary header, it includes the selecting header values when it generates the internal cache key. Thus, a subsequent request with the same values for the selecting headers may generate a cache hit.
If you use the enable-x-accelerator-vary option when running ./configure, Squid looks for a response header named X-Accelerator-Vary. Squid treats this header exactly like the Vary header. Because this is an extension header, however, it is ignored by downstream agents. It essentially provides a means for private content negotiation between Squid and your backend server. In order to use it you must also modify your server application to send the header in its responses. I don't know of any situation in which this header would be useful. If you serve negotiated responses, you probably want to use the standard Vary header so that all agents know what's going on.