I have been working with a problem where ATS adherence to the HTTP spec is causing a client to break.
The issue is propagating header fields on a conditional response. What ATS does it strip all but a few select headers when returning a 304 response to the client. There are two scenarios of interest - * The object is not cached, so ATS strips the conditional headers and sends the request to the origin. It replies with a 200 and the extra headers. ATS constructs a 304 response (because the original client request was conditional) and thereore strips the extra headers. * The object is cached. Whether or not ATS revalidates the object, a 304 with the minimal headers is returned. For this particular issue testing with the origin shows that it returns extra headers in its 304 responses. Why does ATS strip those headers? I originally thought out of compliance with the HTTP spec but the more I read the more I think the ATS is wrong. First is section 7.1 concernting entity header fields, which states "The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields SHOULD be ignored by the recipient and MUST be forwarded by transparent proxies" That would presume to indicate these extra fields should be propagated for any response code, particularly success such as 200 and 304. In section 10.3.5 ["304 Not Modified"] we have this language "If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers." Which implies that the server returning additional headers for a 304 is possibly out of spec, although for a strong validator like ETag extra headers would be permissible, even though ATS will remove them. "If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional." "If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response." At this point I would recommend adding the extra headers or, at a minimum, providing a knob to enable that behavior.
