Bug#388443: apache2: MUST NOT send data in an 304 reply
On Sun, Nov 12, 2006 at 03:21:36PM +0100, Thijs Kinkhorst wrote:
> severity 388443 wishlist
> forwarded 388443 http://issues.apache.org/bugzilla/show_bug.cgi?id=40953
> Christoph Biedl wrote:
> > > >
> > > > | <?php
> > > > | header('HTTP/1.0 304 Not Modified');
> > > > | ?>
> > >
> > > While I can see the argument that apache should perhaps be trimming its
> > See the RfC. It is not "apache should perhaps", it is "apache must".
> I disagree with your interpretation of the RFC here. I think it's
> "apache should" and "the script must" in this case. When Apache runs a
> CGI or PHP script, it essentially passes off the responsibility of
> RFC-compliant output on to the script in question.
This is _not_ a question about the format of the output but about the
transport protocol and hence the responsibility of the server.
> There's many other
> incompliant things, like misspelled headers, a script can send, but
> Apache doesn' stop it from doing that. It's ultimately the script's
No. Sending misspelled hearders only affects the current request.
Sending content in a situation where no content is allowed affects the
next request(s) [and might well be a security problem].
> It could, of course. But that's wishlist. I've filed such a request for
> enhancement upstream.
No. Apache _has_ to ensure _transport_ protocol conformance as much as
the kernel has to enshure that applications can't send IP packets once a
socket is closed.
Cheers, Ralf Mattes