Configure HTTP Status Response Messages

Question

Dear Portal Experts,
we have an issue with the the way portal response codes are put into response messages. The portal sits in an infrastructure which includes multiple security measures, including a reverse proxy. This reverse proxy does not accept certain HTTP responses, which strictly speaking are not standard compliant.
The HTTP response status of interest is HTTP status 304 which means that a requested resource has not been changed since the last request and therefore can be taken from the cache.
The status is returned boldfrom the portal with a bodybold, which is not accepted by the reverse proxy.
Now, what we would like to do is configure the portal to return HTTP status 304 with a header only. Is that possible? We looked into web.xml and web-j2ee-engine.xml but could not find any hint for this. Might easily be, we looked at the wrong places (they were multiple ones...).
Thank you very much,
Michael

Answer 1

According to RFC 2616 the implementation of HTTP code 304 is:
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.
The response MUST include the following header fields:
      - Date, unless its omission is required by section 14.18.1
If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.
      - ETag and/or Content-Location, if the header would have been sent
        in a 200 response to the same request
      - Expires, Cache-Control, and/or Vary, if the field-value might
        differ from that sent in any previous response for the same
        variant
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. 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.
Source: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
@Michael --> I honestly can't imagne that SAP wouldn't confirm to such an RFC (but I cannot guarantee), could it be that another component is adding the body to the 304 code or malforming this reply?
@ SAP employees --> can you confirm if SAP has complied with RFC2616 or not???
Cheers,
Benjamin