You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@redhat.com> on 2006/02/21 15:56:03 UTC
Re: [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
On Tue, Feb 21, 2006 at 11:32:07AM +0000, Nick Kew wrote:
> On Tuesday 21 February 2006 09:49, bugzilla@apache.org wrote:
> > >The fix committed upstream prevents handling of conditional requests with
> > > a CGI script which outputs an explicit (albeit redundant) "Status: 200"
> > > header. This would count as a regression so we would not include that
> > > patch as-is in a RHEL update.
>
> But the explicit 200 response is *not* redundant! It is saying the CGI wants
> to return 200 rather than leave it to the server to return whatever is
> appropriate (e.g. select 200 or 304 according to ap_meets_conditions).
>
> > >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). I think it's
reasonable to perform conditional request processing even if the script
sends an explicit "Status: 200" - indeed, that is exactly the behaviour
that this code originally implemented.
The only actual bug is that r->status_line is respected over r->status
as discussed just now in the other thread by Jeff - that is the bug that
should be fixed, everything else is a workaround.
joe
Re: [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Feb 22, 2006 at 12:53:25PM +0000, Joe Orton wrote:
> On Tue, Feb 21, 2006 at 03:45:39PM +0000, Nick Kew wrote:
> > Not as such. It doesn't need to: it's a MUST in CGI:
> >
> > 7.2.1.3. 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.
If there's nothing else to discuss then given the above I'm -1 on the
util_script.c r370692 change, the r379562 fix for r->status_line
handling is the sufficient and correct way to fix PR 38070 (same goes
for 2.[02].x).
joe
Re: [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Posted by Joe Orton <jo...@redhat.com>.
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:
>
> 7.2.1.3. 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.
joe
Re: [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Posted by Nick Kew <ni...@webthing.com>.
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:
7.2.1.3. 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.
--
Nick Kew