Webcache Returns Content-Type and Content-Length in 304 Header Response
(Doc ID 1134614.1)
Last updated on MARCH 08, 2017
Applies to:Web Cache - Version 10.1.2.0.2 to 220.127.116.11.0 [Release AS10gR2 to Oracle11g]
Information in this document applies to any platform.
- This problem is related to Webcache 10.1.2.X and 18.104.22.168 - 22.214.171.124. This problem does not exist in 126.96.36.199 or higher
- If a request to Webcache is made and a "HTTP-304 Not Modified" is returned, the Header contains the "Content-Type" as "text/html" regardless of what the content to the GET originally was
- For example:
> GET /home/images/thumb09.jpg HTTP/1.1
> User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Accept: */*
> if-Modified-Since: Wed, 10 Mar 2010 08:20:06 GMT
< HTTP/1.1 304 Not Modified
< Date: Wed, 10 Mar 2010 10:00:20 GMT
< Server: OracleAS-Web-Cache-10g/10.1.2.2.0
< Content-Type: text/html
< Content-Length: 0
- As per RFC2616 an HTTP-304 should not return Content-Type or Content-Length:
"10.3.5 304 Not Modified
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
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.”
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!