httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <r...@imdb.com>
Subject bugs R us
Date Sun, 18 Aug 1996 09:24:34 GMT

----- Forwarded message from Brian S Walden -----

Subject: server upgrade
To: www@imdb.com

It appears that the imdb server was recently upgraded to the
Apache/1.2-dev server. You should be aware that there is a nasty bug
that will cause retrieval problems for anyone viewing your site from
behind a cern caching proxy gateway (a fair portion of the world).
The first load of a document works fine, but subseqeunt retrieval
of the same data (e.g. the "back" botton) will end up with the
"Document contains no data" pop-up (for netscape navigator). 
The only way for the client to get it back is to 1) clear the disk cache
2) clear the memory cache and then 3) reload, very annoying.
There is NOT a problem when viewing from behind a netscape proxy
server however, but the bug is with the Apache server, it's just
that the netscape proxy is a little more lienient in handling the bug.
Here is the bug report I've sent into apache:

> Subject: 304 response bug
> To: apache-bugs@apache.org
> Date: Sat, 17 Aug 1996 21:01:47 -0400 (EDT)
> Cc: bsw@panix.com
> 
> emailaddy:	bsw@panix.com
> summary:	missing end-of-header from status-code 304 response
> platform:	Solaris 2.x
> version:	5
> aversion:	Apache/1.2-dev
> symptoms:
>  Documents contain no data when viewed behind a cern3.0A caching proxy
>  gateway after the initial GET. This is because Apache/1.2-dev violates
>  RFC 1945 when returning a status-code 304 response. The RFC specifies that
>  a "blank line" (e.g. CRLF) separates headers from bodies. This is
>  missing from the end of this type of response. The RFC says that
>  a 304 must not include the body, but the separater is not part of
>  the header nor the body, so it should be sent. Since the caching
>  proxy never gets a end-of-header separator it thinks that communication
>  has terminated before everything was sent and just sends an empty
>  document back to the client for subsequent GETs. Here is and example:
>  
>  $ telnet www.apache.org 80
>  GET / HTTP/1.0
>  If-Modified-Since: Thursday, 15-Aug-96 11:58:45 GMT
>   
>  HTTP/1.0 304 Not Modified
>  Date: Sun, 18 Aug 1996 00:40:03 GMT
>  Server: Apache/1.2-dev
>  ETag: "cf30f-1ea7-0"
>  Connection: close
>  Connection closed by foreign host.
>  $
>  
>  Notice the missing blank line between the line that says "Connection: close"
>  (from the Apache server) and the line that says "Connection closed by
>  foreign host." (from telnet itself). Compare this with what HEAD gives you:
>  (which is RFC compliant):
>  
>  $ telnet www.apache.org 80
>  Trying 204.152.144.38...
>  Connected to www.apache.org.
>  Escape character is '^]'.
>  HEAD / HTTP/1.0
>   
>  HTTP/1.0 200 OK
>  Date: Sun, 18 Aug 1996 00:43:40 GMT
>  Server: Apache/1.2-dev
>  Content-Type: text/html
>  Set-Cookie: Apache=bsw6879840329027614; path=/
>  Last-Modified: Sat, 03 Aug 1996 22:54:32 GMT
>  ETag: "cf30f-1ea7-0"
>  Connection: close
>  Vary: Accept
>   
>  Connection closed by foreign host.
>  $ 
>  
>  The blank line is sent here (after the Vary:)
> 
> urlprob:	http://www.apache.org/
> 
> 

----- End of forwarded message from Brian S Walden -----

Mime
View raw message