[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#584298: marked as done (apache2: Apache should not send a 304 response code if the Content-Type has changed)



Your message dated Thu, 3 Jun 2010 15:56:19 +0200
with message-id <201006031556.20323.sf@sfritsch.de>
and subject line Re: Bug#584298: apache2: Apache should not send a 304 response code if the Content-Type has changed
has caused the Debian Bug report #584298,
regarding apache2: Apache should not send a 304 response code if the Content-Type has changed
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
584298: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584298
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: apache2.2-common
Version: 2.2.15-5
Severity: normal

One can change the Content-Type of a file in the .htaccess, e.g. with
ForceType. But if:

1. a browser sends a request corresponding to some file,
2. one changes the Content-Type of the file,
3. the browser sends another request corresponding to the same file
   (e.g. by doing a "reload"),

then Apache sends back a 304 response code, so that the browser
doesn't get the new Content-Type.

-- Package-specific info:
List of enabled modules from 'apache2 -M':
  alias auth_basic authn_file authz_default authz_groupfile
  authz_host authz_svn authz_user autoindex cgi cgid dav dav_svn
  deflate dir env mime negotiation perl reqtimeout rewrite setenvif
  status userdir

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages apache2 depends on:
ii  apache2-mpm-worker            2.2.15-5   Apache HTTP Server - high speed th
ii  apache2.2-common              2.2.15-5   Apache HTTP Server common files

apache2 recommends no packages.

apache2 suggests no packages.

Versions of packages apache2.2-common depends on:
ii  apache2-utils                 2.2.15-5   utility programs for webservers
ii  apache2.2-bin                 2.2.15-5   Apache HTTP Server common binary f
ii  libmagic1                     5.04-2     File type determination library us
ii  lsb-base                      3.2-23.1   Linux Standard Base 3.2 init scrip
ii  mime-support                  3.48-1     MIME files 'mime.types' & 'mailcap
ii  perl                          5.10.1-12  Larry Wall's Practical Extraction 
ii  procps                        1:3.2.8-9  /proc file system utilities

-- no debconf information



--- End Message ---
--- Begin Message ---
On Thursday 03 June 2010, Vincent Lefevre wrote:
> One can change the Content-Type of a file in the .htaccess, e.g.
> with ForceType. But if:
> 
> 1. a browser sends a request corresponding to some file,
> 2. one changes the Content-Type of the file,
> 3. the browser sends another request corresponding to the same file
>    (e.g. by doing a "reload"),
> 
> then Apache sends back a 304 response code, so that the browser
> doesn't get the new Content-Type.

Apache does not keep track of old configurations, therefore it cannot 
know if the content-type has changed. The only way would be to never 
send a 304 if some configuration file is newer than the date given by 
the browser, but this would impact cache usage way too much.

Therefore, I am closing this bug as invalid. You can simply touch all 
files affected by the .htaccess change to make sure that no 304 is 
sent.


--- End Message ---

Reply to: