Closed Bug 78313 Opened 23 years ago Closed 23 years ago

URL will not fully load; document truncated in the cache.

Categories

(Tech Evangelism Graveyard :: English US, defect)

Product:
Tech Evangelism Graveyard
Component:
English US
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: jrgmorrison, Assigned: bc)

Details

(Whiteboard: [cache]) 

Overview Description: 

  This document/URL will not completely load. A truncated copy of the 
  top level HTML document is left in the cache, and it is *always* 1865
  bytes long, but listed as 0 in about:cache, and should be ~13KB.
  (This URL was mentioned as not loading on bug 77634, where they also 
  note that doing View Source let them fully load the page (although I 
  couldn't reproduce that.)

Steps to Reproduce: 

1) (optional) empty/delete your cache; then, set home page to
    http://www.tigris.org/ [this just minimizes the amount of stuff in the
    cache that you need to inspect after the load has been attempted].

3) [if not home page] go to http://www.tigris.org/


Actual Results: page only partially loads
Expected Results: page loads 

Reproducibility: 100% in 4/27, 4/21, 4/13, 4/11, 4/9, 3/28 builds but it works
                 OK in a 4/3 build on win2k

Build Date & Platform Bug Found: 20010042709 win2k and several previous

Additional Information: 

I think this is more likely an http issue, than the cache, but I don't know.

When I look in the NewCache directory, I see three files (plus 3 meta files). 
The HTML document for the home page is 1865 bytes long.

Here is the report from about:cache (4.27 build). Note that this says that the
length of the HTML document is 0 bytes.

----------------------------------------------------------------------
Disk cache device

Usage report: disk cache usage report
Number of entries: 3
Maximum storage size: 7864320
Storage in use: 8231 Bytes

           Key: http://www.tigris.org/
     Data size: 0 Bytes
   Fetch count: 2
 Last Modified: 04/30/01 23:21:25
       Expires: 04/30/01 23:21:25

           Key: 
http://www.tigris.org/branding/style.css?JServSessionIdservlets=h941vkm6v1
     Data size: 4501 Bytes
   Fetch count: 1
 Last Modified: 04/30/01 23:21:25
       Expires: 05/06/01 14:52:32

           Key: http://www.tigris.org/branding/images/logo.gif
     Data size: 3730 Bytes
   Fetch count: 1
 Last Modified: 04/30/01 23:21:25
       Expires: 05/06/01 14:52:45


----------------------------------------------------------------------
Here is the detail record for the HTML document (http://www.tigris.org/)
Note: 1) fetch count is 2, since there is <meta ... 'text/html;charset=...>'
         for iso-8859-1 (no-op), and windows-1252 (re-fetch)

  <META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
  <META CONTENT="text/html; charset=windows-1252" HTTP-EQUIV=CONTENT-TYPE>

      2) I don't know how common the 'Vary: ...' header is in practice.


----------------------------------------------------------------------
key: http://www.tigris.org/
fetch count:

3

last fetched:

04/30/01 23:22:27

last modified:

04/30/01 23:21:25

expires:

04/30/01 23:21:25

Data size:

0

Security:

This document does not have any security info associated with it.

Client:

HTTP

charset:

windows-1252

http-headers:

HTTP/1.1 200 OK
content-type: text/html
date: Tue, 01 May 2001 06:22:40 GMT
server: Apache/1.3.17 (Unix) ApacheJServ/1.1.2 AuthMySQL/2.20
helmloginid: guest
vary: Host
-->darin
-->cache
Assignee: neeti → darin
The same problem on linux I've reported in the bug 78168.
Please os->all.
Whiteboard: [cache]
The severity should be raised on this bug!
I am seeing it on many sites now:

http://sourceforge.net/
http://gcc.gnu.org/
http://www.tigris.org/

and many others...

I should mention that I am behind a squid proxy.

The server at www.tigris.com is buggy.  it responds to a If-Modified-Since
request with the 304 Not Modified response *and* it includes a message body!!
it also tells us that we can reuse the connection.  well... the result is that
the next response we get from that connection will start with <HTML> and so
we'll think the response is a HTTP 0.9 response and not check for any status
line or headers.  As a result, we get the wrong content, and things pretty much
fall apart.  I'm not sure there is anything we can do on our end to handle this.

Bottom line: this server is completely broken!!   --> evangelism.
Assignee: darin → bclary
Component: Networking: HTTP → Evangelism
QA Contact: tever → zach
And what about the other two URLs: gcc.gnu.org and sourceforge.net/projects/...

It's the same buggy HTTP server?

Both gcc.gnu.org and sourceforge.net load correctly for me, either on linux 
on win32. But www.tigris.org does not. 

This bug was filed for www.tigris.org. If you still have problems with those
other web sites, then you should file bugs for those problems.
Ok I've logged a bug 80655 on the sourceforge.net and gcc.gnu.org sites. 
I think that the difference could be that I am behind the squid proxy and that's
why you don't see that bug.


This (http://www.tigris.org/) now worksforme fine probably with the check in of
the level 2 cache. I have linux nightly 2001052121.
Please retest it and mark worksforme if it's fine for you.

Yes, this is now sending a response header with 'Connection: close' when 
sent 'Connection: Keep-Alive'. I assume they cleared something up on that
server. marking WFM.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Marking verified since it didn't happen anymore.
Status: RESOLVED → VERIFIED
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.