when sending status 304 last-modified header is missing using mod_jk

[Edwin Eversdijk <ed...@yahoo.com>]

Hi,

When I send a 304 response status, i send also the lastmodified header. It shows 
on tomcat directly via 8080. But via mod_jk/apache http server it's missing... 
Is this correct behaviour or some bug? Example url: 
http://www.rsscockpit.com/sitemap.do?action=subject&subjectid=52&language=nl

Configuration:

Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8e-fips-rhel5 mod_jk/1.2.28
Tomcat 6.0.29

Regards,

Edwin Eversdijk

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: when sending status 304 last-modified header is missing using mod_jk

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Edwin,

On 6/20/2011 5:01 PM, Edwin Eversdijk wrote:
> When I send a 304 response status, i send also the lastmodified header. It shows 
> on tomcat directly via 8080. But via mod_jk/apache http server it's missing... 

I see the same behavior with this simple JSP in Tomcat 6.0.32:

<%
  response.setHeader("Last-Modified", "Tue, 15 Nov 1994 12:45:26 GMT");
  response.setHeader("X-Test-Header", "12345");
  response.setHeader("Connection", "close");
  response.setHeader("Content-Location", "http://www.google.com/");
  response.setHeader("Vary", "Content-Length");
  response.setHeader("Expires", "Tue, 21 Jun 2011 12:00:00 GMT");
  response.setHeader("Cache-Control", "foo");
  response.setStatus(304);
%>

Neither Last-Modified nor X-Test-Header come back to my browser, though
I was able to set the Connection, Content-Location, Vary, and Expires
headers.

> Is this correct behaviour or some bug?

Looks like httpd is following the spec while Tomcat is not:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5

Specifically:

"
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.
"

Read that very carefully: basically, no entity-headers other than those
explicitly mentioned in that section (Date, ETag, Content-Location,
Expires, Cache-Control, Vary) "RFC SHOULD" be returned under any
circumstances, and, in most circumstances entity-headers other than
those "RFC MUST NOT" be sent.

If anything, I'd say that Tomcat was out-of-spec by allowing those
additional headers to get through.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3/wzYACgkQ9CaO5/Lv0PAcYQCeLU9gxEZ00UHfvejHS9LSe3F1
PIIAoLLhBZCIAAwsbYuFlfPMM1Er0CnZ
=im/i
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org