According to the current HTTP specification, a 304 Not Modified response should not return object headers (with the exception of a few specific exceptions). Quote from section 10.3.5 of RFC 2616 :
If the conditional GET has used strong cache validation, the response SHOULD NOT include other entity headers. Otherwise (i.e., the Conditional GET used a weak validator), the response MUST NOT include other object headers; this prevents inconsistencies between cached entities and updated headers.
And, unfortunately, all extension headers are classified as header headers .
However, looking to the future, in the draft HTTPbis specification intended to replace RFC 2616, the rules are much more relaxed. A quote from the section in section 4.1 of the conditional query specification :
Since the purpose of answer 304 is to minimize the transmission of information when the recipient already has one or more cached views, the sender MUST NOT generate presentation metadata other than the above fields if the specified metadata does not exist for the purpose of the cache update guide.
So, if you are setting up a custom header that will not be classified as presentation metadata, I would expect this to be considered legal under the new rules.
However, no matter what is written in these specifications, you still have to deal with what Apache can support. And from what I saw in the source code, custom headers are still not supported in answer 304.
The place where headers are filtered is located in the ap_http_header_filter function in the /modules/http/http_filters.c file:
In particular, this code:
if (r->status == HTTP_NOT_MODIFIED) { apr_table_do((int (*)(void *, const char *, const char *)) form_header_field, (void *) &h, r->headers_out, "Connection", "Keep-Alive", "ETag", "Content-Location", "Expires", "Cache-Control", "Vary", "Warning", "WWW-Authenticate", "Proxy-Authenticate", "Set-Cookie", "Set-Cookie2", NULL); }
When returning the "Not changed" response (304), the above list of headers is only those that are skipped (except for a few automatically generated headers, such as date and server). And from what I see, there is no easy way to connect to this code to change the behavior.
The bottom line is that this is still not possible in Apache at this time. There is at least one bug report requesting support for other headers, but this is specifically for CORS headers. However, with any luck, they may be more open to support custom headers in general.
But until that happens, the only solution I can offer is to fix the server myself. If you do not want to rebuild the source code, you can even fix the binaries directly. For example, if you only need to support one or two new headers, you can replace some of the existing headers that you are unlikely to use (for example, Set-Cookie2, which is deprecated anyway).
Just find the header names that you want to replace in the Apache bin directory (on Windows you should find them in libhttpd.dll). Then use the binary editor to replace the null-terminated string with the new heading name (of course, it should be the same length or shorter than the heading you are replacing).
I don't know about other operating systems, but I tested it on Windows and it seems to work. Obviously, this is a terrible hack, but if you are desperate enough, you can consider it as an option.