Closed Bug 2694 Opened 26 years ago Closed 24 years ago

Persistent caching of applogic streamed data

Categories

(Core :: Networking: Cache, defect, P3)

Product:
Core
Component:
Networking: Cache
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: alexl, Assigned: pnunn)

Details

(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #312306
http://scopus.netscape.com/bugsplat/show_bug.cgi?id=312306
Imported into Bugzilla on 01/26/99 22:49)

Customer Yellow Services has a Netscape Application Server 2.1 applogic on
Solaris 2.5.1 that returns a GIF image to the browser via the following
"streamResult" methods:

                    streamResultHeader("Content-Type: image/gif");
                    streamResultBinary(bValue, 0, blobSize);

The application itself works well; however, the problem arises when the user
executes the application more than once.  Both Netscape Navigator 3.01 Gold and
Netscape Communicator 4.05 seem to be caching the result when the application is
executed, EVEN when the browser cache settings are cleared and reset to zero.
The consequence of this browser caching is that when the application is executed
a second time with a different docID number, the browser displays the same GIF
image as was returned the first time.

Furthermore, there are three points that should be noted:

1) We do not experience this problem with Microsoft Internet Explorer 4.0.

2) If the user clears the browser cache after each execution of the application
when using Navigator Gold 3.0, the correct GIF image is displayed.  However,
this is not effective when using
Netscape Communicator 4.05.

3) NAS caching is explicitly turned off by including the following command  near
the beginning of the applogic:

     deleteCache(guid());

The returned GIF image is determined by a docID number which is
entered by  the user as part of the application.  The URL of the resulting
image looks like a typical NAS-type URL, like this:

http://hostname/cgi-bin/gx.cgi/GUIDGX-{37e7f845-1069-11d2-ab22-00062912794c}

Applogic code is available for perusal, if needed.

Customer demands an ETA for fix. This is a business-critical Internet imaging
application.
Source code for NAS applogic test case is

   /u/alexl/html/customers/80458/Stream.java

This program randomly generates numbers ranging from 1 thru' 10 and based
on the values the corresponding GIF file is sent.
assigned to PSE
need TFV ASAP!
pse assigned
eng.assigned
Additional info about customer's testing was received 8/7 AM may help
debugsource of problem.

Customer sees that using GET method as opposed to POST to invoke NAS applogic
produces different results in the browser, as follows:

> We tested Internet Explorer (IE4.0) and Netscape Communicator (NS4.05)
> against the TuxBlobSample  Here are the results:

>                                       | GET   | POST
> =====================================
> IE4.0                                 |       |
> a  Retrieved the image.               | pass  | pass
> b  Printed the image.                 | pass  | FAIL
> c  Save image to .gif file (*).       | pass  | pass
> d  Displayed the saved file.          | pass  | FAIL
> e  Printed the saved file.            | pass  | FAIL
> f   Retrieve consecutive images.      | pass  | pass
> =====================================
> NS4.05                                |       |
> a  Retrieved the image.               | pass  | pass
> b  Printed the image.                 | pass  | pass
> c  Save image to .gif file (*).       | FAIL  | FAIL
> d  Displayed the saved file.          | pass  | pass
> e  Printed the saved file.            | pass  | pass
> f   Retrieve consecutive images.      | pass  | FAIL
> =====================================
>
> (*) Browser recognizes file type and saves with proper extension.
>     Netscape save with no extension.
need a test case set up somewhere to demonstrate the problem.  who can do that?
posting a url in the bug report that demostrates the problem is critical
to examining the problem quickly.

also need to test against 4.06.  we have made some general improvments
in this area and may have picked up a fix for this in the process.
In that case tvf would be 4.06.
PSE Email sent to alexl - can we get test case posted so eng can investigate?
Am I right in understanding the only problem is the file name
of the file saved does not have a ".gif" (or ".jpg", etc) extension?
This appears to have been erronously tagged as a mail/news bug and assigned to
me.  I am changing component to browser and reassigning to don
Changing TFV to 5.0.
Edward Hannigan wrote:

    alexl -

   can we get a test case posted asap ?

   ed

 Sorry, Ed. I was off on a vacation day yesterday.

Please see

     http://rendezvous.mcom.com/customers/yellow/80458/Stream.java

This sample applogic has hardcoded GIF file names in it, which you'll have to
change.

Alex
PSE email sent - test case now in, need eng'g update
The nodes were not released because of a reference count problem. Two calls to
NodeLookup were increasing the ref count that were never released.
Checked in gxdsync.cpp v 1.93.2.16
Ignore the previous comment from prefot. He updated the wrong bug.
PSE Email sent - need update ASAP....
Is this really a bug on all platforms?  If so, then it's likely not an FE bug.
PSE Email sent to alexl - pls confrim platforms bug is occuring on.
Verified that customer testing of this error was on Windows NT. But in-house
testing by NAS engineering was with browser on Solaris.
The java file provided in not a good as a test case. Second it is unclear what
the bug is: is it saving the image or images getting cached even when they
should not.

Please clarify the bug in the context of our browser and server. There seems to
be too much noise about other server based application and its code in here.

Second, we need a verifiable test case that demonstates this bug. If you are
unable to get it from the customer due to technical difficulties, we need to
talk to the customer to understand the bug better.

Hannigan, once you have the above info sorted out, please assign it back to
pnunn if this has anything to do with images. She will either fix it or find the
right  person to fix it.
Let me clarify this issue.

The problem is as it was oiginally stated: persistent caching of streamed image
data, despite Communicator settings that are supposed to prevent caching. This
issue is not related to saving or printing images. Strictly caching.

The Stream.java file is the original in-house reproduction of this problem. This
Stream.java was prepared by Technical Support, not the customer.

Relating this issue to "our browser" and "our server" as you demand, thus: this
Stream.java file is compiled to a class file that is installed on the Netscape
Application Server, a Netscape server product (i.e., "our server"), which
happens to communicate, via the Netscape Enterprise Server, with the Netscape
Communicator 4.x browser.

Similarly, but independent of Technical Support's replicatiuon of the problem,
NAS Engineering has also verified this cache persistence of images, via an
applogic (compiled Java class file executed by the Netscape Application Server),
of their own devising.

Please advise me if you would like assitance setting up a replication/test
environment for use by CPD; I will be glad to assist.
Set up a test environment on a webserver and send me the url.
PSE Email sent to alexl - can you assist pnunn in setting up text enviroment?
alexl, please help pnunn in setting up test enviroment ! and post the url in
bugsplat
thanks
Many thanks to Kayshav Dattatri, NAS Engineering, for setting up this test
environment and verifying the behavior.

Check out http://hyperion/streamget.html

If you use Communicator, you will see the same image being painted.
If you come in via Explorer, you will different images.

The explanation on the page should be self explanatory.
PSE email to pnunn - test case and enviroment set up, can work on this bug begin
I'll get to it after a few other higher priority bugs.....
Any new info will show up in this bug report.
I tried to reproduce this bug but when I click on the button Test GET To
Applogic instead of getting a n image this is what I get

"m_pContext = 0 pObj=10624320 m_pGDS = 10624320 pKeyTmp = 10624544
pKeyName=SOFTWARE\KIVA\Enterprise\2.0 RegOpenKeyEx returned 5 pKeyRoot = 0
pkeyroot=0
pkeyCurrentCCS=0 m_pMsgpath=(null) [09/08/98 10:15:15:2] error: OS: No such file
or directory MsgDB: cannot
open message database file '\kdb\en_US\gxmsgdb.kdb', will continue processing
but messages from this file will not
be displayed [09/08/98 10:15:15:2] error: OS: No such file or directory MsgDB:
cannot open message database file
'\kdb\en_US\gxutil.kdb', will continue processing but messages from this file
will not be displayed [09/08/98
10:15:15:2] error: OS: No such file or directory MsgDB: cannot open message
database file '\kdb\en_US\gxcgi.kdb',
will continue processing but messages from this file will not be displayed"

Looks like the the MsgDB is not accessible. Need to fix this problem on the
server hyperion. Alexl please take care of this.
Also added URL to the URL field.
My first thought is that this bug is a symptom of the 'last_modified'
field not being passed properly from netlib to the imagelib. This is
being addressed by another bug report and I am working on it with
Gagen.

I need to check and see if the server is sending back a different value
for "last-modified" field on the image. If it does not, it doesn't change
the need to fix the netlib->imglib data passing, but it might indicate
a problem with the user's server as well.

-pn
PSE update from engineer - not an easy fix, update to follow - This is a high
priority bug with her and it is being looked into.
update: Testing new function which queries the age of an individual image.

Still to be verified: Does the server send back the correct, updated info
for the image? Some webservers do not.
Can anyone get the webserver on the host hyperion running?
thnx,
pn
hyperion belongs to Kayshav Dattatri, who I'll ask to keep the server up. Sorry
for delay.
The server is still down. Any news on getting the test server up?
-pn
from email..

Yes, I am recompliing the sample test case to run on my own machine, since
hyperion had a bad crash and is used by NAS Core Engineering anyway. I'll let
you know when I have it going
yoohoo....
are there any web servers up with this test case?
-pn
PSE email sent - need those servers up !
We need those web servers up to get any further on this. Is this still an issue with the customer?
the web server on hyperion is up, but the cgi gives this
error msg:

Error (0x1 0x0 0x0 0x80020007):

BIND step: could not bind to {B4338B90-2E4F-11D2-8E6A-00805F9143E0}
pnunn, can we get an update ? alexl, the message that was kicked back sounds like the servers are not set up correctly - pls check this out
Sorry for delay on this, folks. I have moved out of tech support and have been
busy with some new duties.

The hyperion server should not be used for this test.

I have asked the techsupport engineer who took over the customer behind this to
set up a NAS server with a test case for you all.

More information soon.

Alex
PSE querying to find out who responsible party is now ..
The test setup is ready. It can be accessed using this link.
http://cosmos.mcom.com/StreamTest/TestSetup/index.html

Click on refresh/reload to load new images. The images are loaded using a random
number generator. A total of five different images can be loaded depending on
the random number.

Contact me if you have any problems. mohanr@netscape.com
hi.
I can't connect to cosmos.mcom.com.
-pn
Need access to cosmos !
Need servers up immediately !
The server is up. Please let me know if you have any trouble.
aaaccccckkkkkkk! I was out sick last week. I just tried cosmos and its down
again.....aaaaaaarrrrrrrgggghhhhh!
-pn
??
translation: I can't connect to the server where the test url is
set up.
reassign PSE to raym
I am sorry, I was on a short vaccation. I just returned this morning. I shall
try to setup the environment again. I shall let you know when it's done.
I will see if this bug still exists in 5.0, once we have a working browser.
Assigning to me.
Assignee: pnunn → paulmac
Status: ASSIGNED → NEW
OS: All
Status: NEW → ASSIGNED
Setting all current Open Critical and Major to M3
Component: NetLib → Networking Library
Product: MozillaClassic → Browser
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Target Milestone: M3
moving off m3 list
Target Milestone: M6
Target Milestone: M6 → M8
Target Milestone: M8 → M10
Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.

Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change.  If this happens, I will fix. ;-)
Component: Networking-Core → Cache
Target Milestone: M10 → M13
cache not in yet, so can't check this out. moving to M13
Bulk move of all Cache (to be deleted component) bugs to new Networking: Cache
component.
Target Milestone: M13 → M16
spam, changing qa contact from paulmac to tever@netscape.com on networking/RDF 
bugs
QA Contact: paulmac → tever
Reassigning paulmac bugs to tever.

neeti
Assignee: paulmac → tever
Status: ASSIGNED → NEW
M16 has been out for a while now, these bugs target milestones need to be 
updated.
Neeti, this looks like a cache bug so I'm reassigning it back.  If I'm wrong 
please assign it to a developer.  This seems rather old so I don't know the 
status.
Assignee: tever → neeti
It seems like this is a bug about Mozilla-Classic (or even older versions of
Netscape) that was preserved for checking out with Seamonkey.
There is no testcase.
There is no activity since 1998.
Resetting clearly invalid milestone field.
(It's not only missed M16, but it seems it wasn't really intended for that.)
Priority: P1 → P3
Target Milestone: M16 → ---
Pam,

I think this bug is no longer valid.
Assignee: neeti → pnunn
Closed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
verif.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.