You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2005/12/29 08:42:19 UTC
DO NOT REPLY [Bug 38070] New: - httpd returns status code 200 instead 304, but logged 304 in log.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38070>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38070
Summary: httpd returns status code 200 instead 304, but logged
304 in log.
Product: Apache httpd-2
Version: 2.2.0
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: All
AssignedTo: bugs@httpd.apache.org
ReportedBy: standby24x7@gmail.com
Version httpd-2.2.0
Use mod_cgi
This symptom has been reported against older apaches before.
apache 1.3 http://archive.apache.org/gnats/5640
apache 2.0 http://issues.apache.org/bugzilla/show_bug.cgi?id=37166
But the solution is not included in current 1.3 and 2.0 sources.
And this time,Ireport it against apache 2.2.0.
Symptom:
Browser access cgi program multiple times.
1st time, httpd returns status code 200 packet and logged status 200
in accesslog. Correct screen is display.
2nd time, httpd returns status code 200 without BODY and logged
status 304 in accesslog. Blank screen is display.
Sample script:
http://issues.apache.org/bugzilla/attachment.cgi?id=16757
Fix patchlet:
http://archive.apache.org/gnats/5640
I hope apache developer will include the patch into all 3
version of httpd souce trees.
Regards,
Masanari Iida
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38070>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38070
------- Additional Comments From nick@webthing.com 2006-02-21 22:29 -------
(In response to Dave Sparks)
1. What a proxy can do with a response is totally independent of CGI rules.
They operate at different levels, and affect different agents.
2. Thanks for the headsup re: mod_asis documentation. I've just fixed
the .xml source, so that should propagate through to the live docs in due
course.
3. You keep telling us you had to patch a problem, but I still can't see a
problem description. If we had one, maybe we could fix it, as we have done
the bug that was clearly and accurately described in this bug report.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
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
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 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: DO NOT REPLY [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 09:49, bugzilla@apache.org wrote:
> ------- Additional Comments From standby24x7@gmail.com 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 (jorton@redhat.com) 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
DO NOT REPLY [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38070>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38070
------- Additional Comments From standby24x7@gmail.com 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.
>Comment #5 From Joe Orton (jorton@redhat.com) 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.
>
>I've prepared a (simpler) alternative patch, which fixes the real issue and will
>make packages available for testing.
>
--- 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?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38070>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38070
------- Additional Comments From nick@webthing.com 2006-02-21 16:56 -------
The CGI spec. is quite explicit on this:
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.
so a patch that causes it to change that breaks CGI.
Having said that, for the particular example reported in this bug, Joe's fix
is better in practical terms. That's because the CGI script itself misused
"status". See todays thread on dev@httpd.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38070>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38070
------- Additional Comments From nick@webthing.com 2006-02-03 01:39 -------
(In reply to comment #3)
> Are you sure you don't want to convert a CGI-generated 200 to a 304 when the
> HTTP conditions fail?
There are two cases. If the CGI *explicitly* generates a Status: header, we
should honour it. If not, then we just need to generate whatever is
appropriate - usually 200, or 302 if the CGI emitted a Location header.
> ap_scan_script_header_err is also called by mod_asis . I
The crucial difference thare is that mod_asis isn't documented as having a
Status header (though I guess it might, if it goes through the same parsing as
CGI).
> use mod_asis extensively, with files which include Last-Modified: and ETag:
> headers, and it would be disastrous to return 200 when 304 would be
appropriate.
Your asis doesn't say "Status: foo"? Then the patch won't affect it.
>
> Admittedly, I've had to patch both mod_asis.c and util_script.c to get the
right
> results, but my server seems to return the responses I expect.
If you're saying we've got something wrong in the patch, please explain.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38070>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38070
nick@webthing.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From nick@webthing.com 2006-02-04 18:50 -------
Fixed in:
trunk: http://svn.apache.org/viewcvs?rev=370692&view=rev
2.0: http://svn.apache.org/viewcvs?rev=374894&view=rev
2.2: http://svn.apache.org/viewcvs?rev=374895&view=rev
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38070>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38070
------- Additional Comments From standby24x7@gmail.com 2006-01-15 07:14 -------
I have posted this symptom to apache users mailing list.
Nick Kew reply to the question.
From: Nick Kew <> Mailed-By: httpd.apache.org
Reply-To: users httpd apache org
To: users@httpd apache org
Date: Jan 15, 2006 4:26 AM
Subject: Re: [users@httpd] Bug or feature?
On Saturday 14 January 2006 18:04, Masanari Iida wrote:
> Hi,
>
> I would like to ask the list members if following are
> bug or feature of apache.
>
> Use following sample script,
> Apache version: ANY (1.3, 2.0 and 2.2)
>
> #!/bin/sh
> cat <<EOT
> Status: 200 OK
> Last-Modified: Tue, 15 Feb 2005 15:00:00 GMT
> Content-Type: text/html
>
> Hello world
> EOT
Interesting. I can confirm that your CGI script with an If-Modified-Since
header later than the Last-Modified date supplied by the script does
indeed return 200 with no body. That's broken, but is it Apache or
the script that's at fault[1]?
RFC2616 says of If-Modified-Since:
c) If the variant has not been modified since a valid If-^M
Modified-Since date, the server SHOULD return a 304 (Not^M
Modified) response.^M
That makes sense: the script is stupid but technically within its rights
to send the 200 unconditionally. So Apache should presumably
accommodate it by ignoring the If-Modified-Since header and
returning 200 with the full body.
If that's not already in bugzilla, you might consider entering it there.
[1] It's both, of course.
--
Nick Kew
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38070>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38070
Dave.Sparks@sisyphus.demon.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Dave.Sparks@sisyphus.demon.c
| |o.uk
------- Additional Comments From Dave.Sparks@sisyphus.demon.co.uk 2006-02-02 21:06 -------
Are you sure you don't want to convert a CGI-generated 200 to a 304 when the
HTTP conditions fail? ap_scan_script_header_err is also called by mod_asis . I
use mod_asis extensively, with files which include Last-Modified: and ETag:
headers, and it would be disastrous to return 200 when 304 would be appropriate.
Admittedly, I've had to patch both mod_asis.c and util_script.c to get the right
results, but my server seems to return the responses I expect.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38070>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38070
------- Additional Comments From Dave.Sparks@sisyphus.demon.co.uk 2006-02-21 20:39 -------
Notwithstanding a semantically flawed sentence in a draft which expired over six
years ago, a CGI script which includes cache validation headers in its response
cannot rely on a status code of 200 being returned to the client. An HTTP/1.1
proxy may return a 304 response without troubling the server; or if it has to
transmit the request via an HTTP/1.0 proxy it may convert a conditional GET to a
HEAD whose 200 response may be converted to a 304 if the conditions are
satisfied. Insisting that a 200 response with cache validation headers be
transmitted unchanged is futile.
The draft supposedly encodes current CGI practice, but I suspect that in the
area of cache validation headers in CGI-generated responses there is no current
practice to encode.
The documentation for mod_asis says "A Status: header is also required", where
'required' implies that it can never be omitted. Since the header handling is
common with mod_cgi the documentation is plainly wrong. I have removed the
Status line from my 802 .asis files with no ill effects.
Whatever the outcome of the argument about "Status: 200" with a "Last-Modified:"
which satisfies a conditional request, I'm going to have to continue to patch
ap_scan_script_header_err to include my "ETag:" headers in the check.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38070>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38070
------- Additional Comments From nick@webthing.com 2006-01-20 02:38 -------
Fixed in trunk: r370692
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org