On Tuesday 21 February 2006 09:49, [EMAIL PROTECTED] wrote:
> ------- Additional Comments From [EMAIL PROTECTED] 2006-02-21 10:49
> ------- I have opened Red Hat's bugzilla case and ask RH to back
> port your patch into RH's.
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176663
>
> Then RH's engineer wrote in comment #5.
... who appears to be our jorton:-)
> >Comment #5 From Joe Orton ([EMAIL PROTECTED]) on 2006-02-20 10:49 EST
>
> [reply]
>
> >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.
> --- httpd-2.0.52/server/util_script.c.cgistatus
> +++ httpd-2.0.52/server/util_script.c
> @@ -462,6 +462,13 @@
>
> if ((cgi_status == HTTP_OK) && (r->method_number == M_GET)) {
> cond_status = ap_meets_conditions(r);
> +
> + /* In case an explicit Status: header had set
> + * r->status_line, then unset it here, so that the
> + * actual handler return value will be honoured. */
> + if (cond_status != OK) {
> + r->status_line = NULL;
> + }
> }
> apr_table_overlap(r->err_headers_out, merge,
> APR_OVERLAP_TABLES_MERGE);
>
> With Red Hat's fix, apache with sample cgi return 200,304,304,304.
> With Nick's fix, apache with sample cgi return 200,200,200,200.
> Both cases, no more white (empty) display.
> But,which one is better solution?
--
Nick Kew
