281486 - When redirect(302) URL of an HTML element(<img>) is changed when reload and "304"is returned for the new redirect URL, old redirect URL's data is used for the HTML element

Status: RESOLVED DUPLICATE of bug 89419

(Core :: Networking: Cache, defect)

Description

[WADA:World Anti-bad-Duping Agency]

When (A) server application returns "302 Found" and redirects to random
         JEPG file for a URL(eg. <img src="random.php">),
 and (B) all the redirected files are already cached,
 and (C) main HTML which includes link to the URL is already cached,
nexts occurs on "Reload" of the main HTML.
 (1) "304 Not Modified" is returned to "HTTP GET" to main HTML,
 (2) "302 Found" is retunred for <img src="random.php">,
      and redirected to different URL before reload,
 (3) "304 Not Modified" is also returned to the newly redirected URL
     for the <img>.
In this case, Mozilla doesn't replace image content, still displays image
contents of old redirected URL.

Overall flow is as follows.
 (1) Main html inclides <img src="random.php"> 
 (2) Main HTML is cached
 (3) All the redirected JPEG files are cached.
 (5) Shift+Reload main HTML
     random.php redirect to white.jpg and white.jpg is displayed
 (6) Reload of main HTML
 (6-1) HTTP GET Main-HTML with "If-Modified-Since"
 (6-2) 304 Not Modified
 (6-3) HTTP GET random.php
       (URL of the IMG element is not changed.)
 (6-4) 302 Found and redirect to red.jpg 
       (Redirected URL for the IMG element is changed from previous.)
 (6-5) HTTP GET red.jpg with "If-Modified-Since"
 (6-6) 304 Not Modified
 (6-6) Displayed image is still white.jpg. Not replaced by red.jpg.

Problem when similar situation ot Bug 279048.
But 279048 case is problem when is URL at (6-3) is change by JavaScript,
while this bug's case is problem when redirected URL at step (6-4) is changed by
server.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Attachment: HTTP Header log

Live HTTP Hedaders log of step (5) to step (7) in next test.

[Problem recereation test procedure]

(1) Preparation for recreation test
  (1-1) Change cache option/Clear cache
	- Compare the page in the cache to the page on network
	  "Every time I view the page"
	- Clear chace
	(This step doesn't have relation to problem recreation test.)
	(But this makes test result clear.)
  (1-2) Go http://bside.homeunix.net/webpage/bug_test/050206/preload.html
	THis HTML load next 7 jpeg files into cache.
	  <img src="black.jpg">black.jpg<br />
	  <img src="blue.jpg">blue.jpg<br />
	  <img src="green.jpg">green.jpg<br />
	  <img src="pink.jpg">pink.jp<br />
	  <img src="red.jpg">red.jpg<br />
	  <img src="white.jpg">white.jpg<br />
  (1-3) Go http://bside.homeunix.net/webpage/bug_test/050206/
	This HTML have next three <img> tags.
	   <img src="random.php">
	   <img src="random_nocache.php">
	   <img src="random_ctype.php">
	These PHP script returns "302 Found"
	and redirects to one of above JPEG files randomly.
	Diferrence among random.php, random_nocache.php and random_ctype.php
	is returned HTTP headers such as Cache-Control: when "302 Not found".
	Objective of the difference is to see that
	the difference has no relation to this bug.
  (1-4) Shift+Reload http://bside.homeunix.net/webpage/bug_test/050206/
	several times, until three different color images are displayed.
(4) Start Live HTTP Headers
(5) Shift+Reload of URL at step (1-2)
      ( http://bside.homeunix.net/webpage/bug_test/050206/preload.html )
      in order to get HTTP header log for getting above 7 jpeg files
      and to put them in cache.
(6-1) First Reload of of URL at step (1-3)
      ( http://bside.homeunix.net/webpage/bug_test/050206/ )
      Althogh server returns "302 Found" and rediret to different JPEG file,
      displyed images are not changed.
(6-2) Second Reload of of URL at step (1-3)
      ( http://bside.homeunix.net/webpage/bug_test/050206/ )
      Althogh server returns "302 Found" and rediret to different JPEG file,
      displyed images are not changed.
(6-3) Third Reload of of URL at step (1-3)
      ( http://bside.homeunix.net/webpage/bug_test/050206/ )
      Althogh server returns "302 Found" and rediret to different JPEG file,
      displyed images are not changed.
(7) Shift+Reload of URL at step (1-3)
      ( http://bside.homeunix.net/webpage/bug_test/050206/ )
    Since the HTML is get again from server,
    displayed images are changed.
(8) End of Live HTTP Header log

Comment 2

[WADA:World Anti-bad-Duping Agency]

To Darin Fisher: This may be DUP of Bug 89419.

Comment 3

[WADA:World Anti-bad-Duping Agency]

No Cache-Control: related problem is involved in HTTP protocol level flow.
So I think that this is renderer's side problem instead of internal cache
control mechanism itself.
But from client user'view & servlet programer's view, this looks like
Cache-Control: protocol violation, since final display is same as before.
And I don't know whether "using cached data" is involved in Component=Cache or not.
Then I set Component=Cache initially.
If wrong, change it to appropriate one, please. 

Comment 4

[WADA:World Anti-bad-Duping Agency]

Attachment: TEST Case-2 : HTTP Header log

Live HTTP Hedaders log of next test case.

[Test Case-2]
Redirected JPEG Image file is not cached.
(cache for JPEG file is inhibited.)
Difference from test case in comment #1 is (6) & (7) in next steps.
 
   (1) Reload
       ( http://bside.homeunix.net/webpage/bug_test/no-store/ )
   (2) HTTP GET /webpage/bug_test/no-store/
   (3) 304 Not Modified
   (4) HTTP GET /webpage/bug_test/no-store/random.php
   (5) 302 Found
       Location: http:// ..... /webpage/bug_test/no-store/xxx.jpg
   (6) HTTP GET /webpage/bug_test/no-store/xxx.jpg
       Next header is added by Moziia
       due to Cache-Control: no-store at step (7).
	 Cache-Control: max-age=0
   (7) Next headers & jpeg data is returned,
       instead of returning "304 Not Modified".
	 200 OK
	 Cache-Control: no-store, max-age=3600
	 Expires: Wed, 09 Feb 2005 07:08:47 GMT
	 Last-Modified: Fri, 24 Sep 2004 08:57:36 GMT
	 Accept-Ranges: bytes
	 Content-Length: 346
	 Content-Type: image/jpeg
   (8) Displayed JPEG content are replaced by new one.
       (Problem does'nt occur).

Comment 5

[WADA:World Anti-bad-Duping Agency]

Next is about:cache data for redirected URL's after reload test in comment #0.
 (Today's data. Timestamp & Fetch count is different from HTTP log data.)
>[Memory cache device]
>(1)Key: http://bside.homeunix.net/webpage/bug_test/050206/random.php
>       Data size: 24000 bytes
>     Fetch count: 4
>   Last modified: 2005-02-09 18:14:06
>         Expires: 2005-02-09 18:19:05
>(2)Key: http://bside.homeunix.net/webpage/bug_test/050206/random_nocache.php
>       Data size: 24000 bytes
>     Fetch count: 4
>   Last modified: 2005-02-09 18:14:06
>         Expires: 2005-02-09 18:19:05
>(3)Key: http://bside.homeunix.net/webpage/bug_test/050206/random_ctype.php
>       Data size: 24000 bytes
>     Fetch count: 4
>   Last modified: 2005-02-09 18:14:06
>         Expires: 2005-02-09 18:19:06
>(4)Key: http://bside.homeunix.net/webpage/bug_test/050206/random.php
>       Data size: 0 bytes
>     Fetch count: 4
>   Last modified: 2005-02-09 18:50:48
>         Expires: 1970-01-01 09:00:00
>[Disk cache device]
>(5)Key: http://bside.homeunix.net/webpage/bug_test/050206/random_ctype.php
>       Data size: 0 bytes
>     Fetch count: 4
>   Last modified: 2005-02-09 18:50:49
>         Expires: 1970-01-01 09:00:00
>(6)Key: http://bside.homeunix.net/webpage/bug_test/050206/random_nocache.php
>       Data size: 0 bytes
>     Fetch count: 4
>   Last modified: 2005-02-09 18:50:48
>         Expires: 1970-01-01 09:00:00

When reload is executed, "Fetch count" of all above entries was incremented and
timestamp of (4),(5),(6) was updated on each reload.
However, timestamp of (1),(2),(3) was not updated on any reload.

Since random.php returns "Cache-Control:no-store" when returns "302 Found",
(4) is placed in Memory cache,
Since random_nocache.php & random_ctype.php returns "Cache-Control:no-cache"
when returns "302 Found", (5) & (6) are placed in Disk Cache.
And data length of (4),(5),(6) is ZERO and Expires is set to 1970/1/1.
So I guess these are is entries for "302 Found" response itself.

I guess entry (1),(2),(3) are entries to hold redirect related information.
If this entry is for holding redirected URL information and pointer to cache
entry of redirected URL, this entry should be updated when "302 Found" is
received even when "304 Not Modified" is returned for redirected URL.

Comment 6

[WADA:World Anti-bad-Duping Agency]

But if (1),(2),(3) doesn't have redirect related information, there is no way to
know where redirected, because cache is inhibited then (4),(5),(6) has no data... 

Comment 7

[WADA:World Anti-bad-Duping Agency]

Next is about:cache data for redirected URL's after reload test case-2 in
comment #4 (200 & JPEG data is rerurned in stead of "304 Not Modified").
 (Today's data. Timestamp & Fetch count is different from HTTP log data.)

>[Memory cache device]
>(7)Key: http:// ...  /webpage/bug_test/no-store/random_nocache.php
>      Data size: 24000 bytes
>    Fetch count: 1
>  Last modified: 2005-02-10 09:46:10
>        Expires: 1970-01-01 09:00:00
>(8)Key: http:// ... /webpage/bug_test/no-store/random.php
>      Data size: 24000 bytes
>    Fetch count: 1
>  Last modified: 2005-02-10 09:46:13
>        Expires: 1970-01-01 09:00:00
>(9)Key: http:// ...  /webpage/bug_test/no-store/random.php
>      Data size: 0 bytes
>    Fetch count: 7
>  Last modified: 2005-02-10 09:46:10
>        Expires: 1970-01-01 09:00:00
> [Disk cache device]
>(10)Key: http:// ... /webpage/bug_test/no-store/random_nocache.php
>      Data size: 0 bytes
>    Fetch count: 7
>  Last modified: 2005-02-10 09:46:10
>        Expires: 1970-01-01 09:00:00

Since random.php returns "Cache-Control:no-store" when returns "302 Found",
(9) is placed in Memory cache,
Since random_nocache.php returns "Cache-Control:no-cache"
when returns "302 Found", (10) is placed in Disk Cache.

Fetch count of (9),(10) is incremented on each reload, but Fetch count of
(7),(8) is always 1.
Timestamp of (8)&(9) are same and timestapm of (7)&(10) is same.
These are updated at every reload.

I think that one of the cause of this bug's problem is ;
  No update of (1),(2),(3) in comment #5,
  when "304 Not Modified" is returned for redirected URL
  following redirection by "302 Found".

Comment 8

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 89419 ***