httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject Re: [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Date Wed, 22 Feb 2006 12:53:25 GMT
On Tue, Feb 21, 2006 at 03:45:39PM +0000, Nick Kew wrote:
> On Tuesday 21 February 2006 14:56, Joe Orton wrote:
> > > > >I've prepared a (simpler) alternative patch, which fixes the real
> > > > > issue and will make packages available for testing.
> > >
> > > Sure, it's a better fix to the particular example that was posted.  But
> > > that's only because that example was a misuse of the CGI "Status" header.
> > > Taken more generally, that patch breaks CGI by *preventing* it doing
> > > something that the CGI spec permits.
> >
> > Well, interaction between CGI scripts and conditional request processing
> > is not specified by the CGI spec (AFAICS anyway).
> Not as such.  It doesn't need to: it's a MUST in CGI:
> Status  
>  The "Status" header field is used to indicate to the server what status code 
> the server MUST use in the response message.
> Your patch breaks that, plain and simple.

Given that the CGI spec does not cover conditional request processing I 
don't think that's relevant.  There will always be ways that the server 
will override an explicit "Status: 200" - the byterange filter would do 
it (before it was changed, for incidental reasons); mod_cgi will now do 
it if a Location header is also sent, since Jeff has just fixed the real 
r->status_line handling bug on the trunk.

As Dave Sparks pointed out in the PR, any downstream HTTP proxy may turn 
a conditional HTTP request into a 304, so it's not particularly useful 
to allow the CGI script to force it at the origin.  Any script which 
relies on that particular behaviour is broken anyway, even if the CGI 
spec is oblivious to that fact.


View raw message