You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Havard <br...@kheldar.apana.org.au> on 2000/11/17 15:22:06 UTC
304's broken?
I'm seeing badly broken responses to IMS GET requests where the response is
a 304. I'm guessing this is releated to the recent changes to HEAD
processing but I haven't spent any time tracing it yet. Is it only me or
are all platforms affected?
The problem I'm seeing is that some junk is sent before an apparently
correct 304 response header (err, actually the content length shouldn't be
0). The client is Netscape 4.61 (OS/2). The data of the response looks like
this:
--------------------------------- DATA -----------------------------------
0000 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 63 6C 6F 73 Connection: clos
0010 65 0D 0A 45 54 61 67 3A 20 22 30 2D 37 34 62 2D e..ETag: "0-74b-
0020 38 62 36 32 34 36 30 30 22 0D 0A 0D 0A 00 30 30 8b624600".....00
0030 30 20 31 30 3A 34 36 3A 32 36 20 47 4D 54 0D 0A 0 10:46:26 GMT..
0040 53 65 72 76 65 72 3A 20 41 70 61 63 68 65 2F 32 Server: Apache/2
0050 2E 30 61 38 2D 64 65 76 20 28 4F 53 2F 32 29 0D .0a8-dev (OS/2).
0060 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00F0 00 00 00 00 00 48 54 54 50 2F 31 2E 31 20 33 30 .....HTTP/1.1 30
0100 34 20 4E 6F 74 20 4D 6F 64 69 66 69 65 64 0D 0A 4 Not Modified..
0110 44 61 74 65 3A 20 46 72 69 2C 20 31 37 20 4E 6F Date: Fri, 17 No
0120 76 20 32 30 30 30 20 31 30 3A 34 36 3A 32 36 20 v 2000 10:46:26
0130 47 4D 54 0D 0A 53 65 72 76 65 72 3A 20 41 70 61 GMT..Server: Apa
0140 63 68 65 2F 32 2E 30 61 38 2D 64 65 76 20 28 4F che/2.0a8-dev (O
0150 53 2F 32 29 0D 0A 4C 61 73 74 2D 4D 6F 64 69 66 S/2)..Last-Modif
0160 69 65 64 3A 20 54 75 65 2C 20 31 33 20 4A 75 6E ied: Tue, 13 Jun
0170 20 32 30 30 30 20 30 32 3A 33 37 3A 31 32 20 47 2000 02:37:12 G
0180 4D 54 0D 0A 45 54 61 67 3A 20 22 30 2D 37 34 62 MT..ETag: "0-74b
0190 2D 38 62 36 32 34 36 30 30 22 0D 0A 41 63 63 65 -8b624600"..Acce
01A0 70 74 2D 52 61 6E 67 65 73 3A 20 62 79 74 65 73 pt-Ranges: bytes
01B0 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 ..Content-Length
01C0 3A 20 30 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A : 0..Connection:
01D0 20 63 6C 6F 73 65 0D 0A 43 6F 6E 74 65 6E 74 2D close..Content-
01E0 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D Type: text/html.
01F0 0A 0D 0A ...
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: 304's broken?
Posted by rb...@covalent.net.
Found this bug and I am about to fix it. The problem is once again Apache
trying to outsmart itself. :-)
Basically, right now, if we get a 304 response code, then Apache goes
through the process of taking the headers_out table and converting it to a
stream of data, which it sends down the filter stack. Then, the HTTP
header filter sees that we are sending data, and it converts the table
into a stream and sends that stream. With both those streams, the server
gets pretty screwed up. The solution is simple, don't have
ap_send_error_response try to send the headers. If it just removes the
Content-Length filter so we won't re-compute the content-lenght, and sends
an EOS, we get the right headers automagically.
Committing ASAP.
Ryan
On Sat, 18 Nov 2000, Brian Havard wrote:
> I'm seeing badly broken responses to IMS GET requests where the response is
> a 304. I'm guessing this is releated to the recent changes to HEAD
> processing but I haven't spent any time tracing it yet. Is it only me or
> are all platforms affected?
>
> The problem I'm seeing is that some junk is sent before an apparently
> correct 304 response header (err, actually the content length shouldn't be
> 0). The client is Netscape 4.61 (OS/2). The data of the response looks like
> this:
>
> --------------------------------- DATA -----------------------------------
> 0000 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 63 6C 6F 73 Connection: clos
> 0010 65 0D 0A 45 54 61 67 3A 20 22 30 2D 37 34 62 2D e..ETag: "0-74b-
> 0020 38 62 36 32 34 36 30 30 22 0D 0A 0D 0A 00 30 30 8b624600".....00
> 0030 30 20 31 30 3A 34 36 3A 32 36 20 47 4D 54 0D 0A 0 10:46:26 GMT..
> 0040 53 65 72 76 65 72 3A 20 41 70 61 63 68 65 2F 32 Server: Apache/2
> 0050 2E 30 61 38 2D 64 65 76 20 28 4F 53 2F 32 29 0D .0a8-dev (OS/2).
> 0060 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00F0 00 00 00 00 00 48 54 54 50 2F 31 2E 31 20 33 30 .....HTTP/1.1 30
> 0100 34 20 4E 6F 74 20 4D 6F 64 69 66 69 65 64 0D 0A 4 Not Modified..
> 0110 44 61 74 65 3A 20 46 72 69 2C 20 31 37 20 4E 6F Date: Fri, 17 No
> 0120 76 20 32 30 30 30 20 31 30 3A 34 36 3A 32 36 20 v 2000 10:46:26
> 0130 47 4D 54 0D 0A 53 65 72 76 65 72 3A 20 41 70 61 GMT..Server: Apa
> 0140 63 68 65 2F 32 2E 30 61 38 2D 64 65 76 20 28 4F che/2.0a8-dev (O
> 0150 53 2F 32 29 0D 0A 4C 61 73 74 2D 4D 6F 64 69 66 S/2)..Last-Modif
> 0160 69 65 64 3A 20 54 75 65 2C 20 31 33 20 4A 75 6E ied: Tue, 13 Jun
> 0170 20 32 30 30 30 20 30 32 3A 33 37 3A 31 32 20 47 2000 02:37:12 G
> 0180 4D 54 0D 0A 45 54 61 67 3A 20 22 30 2D 37 34 62 MT..ETag: "0-74b
> 0190 2D 38 62 36 32 34 36 30 30 22 0D 0A 41 63 63 65 -8b624600"..Acce
> 01A0 70 74 2D 52 61 6E 67 65 73 3A 20 62 79 74 65 73 pt-Ranges: bytes
> 01B0 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 ..Content-Length
> 01C0 3A 20 30 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A : 0..Connection:
> 01D0 20 63 6C 6F 73 65 0D 0A 43 6F 6E 74 65 6E 74 2D close..Content-
> 01E0 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D Type: text/html.
> 01F0 0A 0D 0A ...
>
> --
> ______________________________________________________________________________
> | Brian Havard | "He is not the messiah! |
> | brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
> ------------------------------------------------------------------------------
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: 304's broken?
Posted by rb...@covalent.net.
On Fri, 17 Nov 2000 rbb@covalent.net wrote:
>
> I think I know what this is, and I was hoping it wasn't an issue. I'll
> look at this when I get to the office today.
Re-reading that, it sounds bad. I thought of this issue when dealing with
the HEAD stuff, put it on my list of things to investigate, and I haven't
gotten to it yet. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: 304's broken?
Posted by rb...@covalent.net.
I think I know what this is, and I was hoping it wasn't an issue. I'll
look at this when I get to the office today.
Ryan
On Sat, 18 Nov 2000, Brian Havard wrote:
> I'm seeing badly broken responses to IMS GET requests where the response is
> a 304. I'm guessing this is releated to the recent changes to HEAD
> processing but I haven't spent any time tracing it yet. Is it only me or
> are all platforms affected?
>
> The problem I'm seeing is that some junk is sent before an apparently
> correct 304 response header (err, actually the content length shouldn't be
> 0). The client is Netscape 4.61 (OS/2). The data of the response looks like
> this:
>
> --------------------------------- DATA -----------------------------------
> 0000 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 63 6C 6F 73 Connection: clos
> 0010 65 0D 0A 45 54 61 67 3A 20 22 30 2D 37 34 62 2D e..ETag: "0-74b-
> 0020 38 62 36 32 34 36 30 30 22 0D 0A 0D 0A 00 30 30 8b624600".....00
> 0030 30 20 31 30 3A 34 36 3A 32 36 20 47 4D 54 0D 0A 0 10:46:26 GMT..
> 0040 53 65 72 76 65 72 3A 20 41 70 61 63 68 65 2F 32 Server: Apache/2
> 0050 2E 30 61 38 2D 64 65 76 20 28 4F 53 2F 32 29 0D .0a8-dev (OS/2).
> 0060 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00F0 00 00 00 00 00 48 54 54 50 2F 31 2E 31 20 33 30 .....HTTP/1.1 30
> 0100 34 20 4E 6F 74 20 4D 6F 64 69 66 69 65 64 0D 0A 4 Not Modified..
> 0110 44 61 74 65 3A 20 46 72 69 2C 20 31 37 20 4E 6F Date: Fri, 17 No
> 0120 76 20 32 30 30 30 20 31 30 3A 34 36 3A 32 36 20 v 2000 10:46:26
> 0130 47 4D 54 0D 0A 53 65 72 76 65 72 3A 20 41 70 61 GMT..Server: Apa
> 0140 63 68 65 2F 32 2E 30 61 38 2D 64 65 76 20 28 4F che/2.0a8-dev (O
> 0150 53 2F 32 29 0D 0A 4C 61 73 74 2D 4D 6F 64 69 66 S/2)..Last-Modif
> 0160 69 65 64 3A 20 54 75 65 2C 20 31 33 20 4A 75 6E ied: Tue, 13 Jun
> 0170 20 32 30 30 30 20 30 32 3A 33 37 3A 31 32 20 47 2000 02:37:12 G
> 0180 4D 54 0D 0A 45 54 61 67 3A 20 22 30 2D 37 34 62 MT..ETag: "0-74b
> 0190 2D 38 62 36 32 34 36 30 30 22 0D 0A 41 63 63 65 -8b624600"..Acce
> 01A0 70 74 2D 52 61 6E 67 65 73 3A 20 62 79 74 65 73 pt-Ranges: bytes
> 01B0 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 ..Content-Length
> 01C0 3A 20 30 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A : 0..Connection:
> 01D0 20 63 6C 6F 73 65 0D 0A 43 6F 6E 74 65 6E 74 2D close..Content-
> 01E0 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D Type: text/html.
> 01F0 0A 0D 0A ...
>
> --
> ______________________________________________________________________________
> | Brian Havard | "He is not the messiah! |
> | brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
> ------------------------------------------------------------------------------
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------