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



Tech Evangelism Graveyard
English US
17 years ago
3 years ago


(Reporter: John Morrison, Assigned: bc)



(Whiteboard: [cache])



17 years ago
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

     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:


last fetched:

04/30/01 23:22:27

last modified:

04/30/01 23:21:25


04/30/01 23:21:25

Data size:



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






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

Comment 1

17 years ago

Comment 2

17 years ago
Assignee: neeti → darin

Comment 3

17 years ago
The same problem on linux I've reported in the bug 78168.
Please os->all.


17 years ago
Whiteboard: [cache]

Comment 4

17 years ago
The severity should be raised on this bug!
I am seeing it on many sites now:


and many others...

I should mention that I am behind a squid proxy.

Comment 5

17 years ago
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

Comment 6

17 years ago
And what about the other two URLs: gcc.gnu.org and sourceforge.net/projects/...

It's the same buggy HTTP server?

Comment 7

17 years ago
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.

Comment 8

17 years ago
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.

Comment 9

17 years ago
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.

Comment 10

17 years ago
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.
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 11

17 years ago
Marking verified since it didn't happen anymore.

Comment 12

17 years ago
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
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.