Open Bug 282198 Opened 19 years ago Updated 2 years ago

If SRC URL of IFRAME is static but the URL is redirected to other URL by "302 Found", HTTP GET when "Reload" is issued to the last redirected URL instead of URL on IFRAME

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

People

(Reporter: World, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(1 file)

HTTP Header log of problem recreation test
3.46 KB, text/plain
Details 
This is spin off of Bug 89419 comment #52.

Rough flow of recreation test is as follows.
 (1) URL-main.html contains IFRAME SRC=URL-X.php
     URL-main.html is cached and not modified.
 (2) URL-X.php is redirected to one of URL-1.jpg, URL-2.jpg, ..., URL-6.jpg.
     URL-1.jpg, URL-2.jpg, ..., URL-6.jpg are cached and not modified.
 (3) Shift+Reload of URL-main.html
   (3-1) HTTP GET URL-main.html with If-Modified-Since
   (3-2) 304 Not Modified
   (3-3) HTTP GET URL-X.php
   (3-4) 302 Found
         Location: URL-n.jpg
   (3-5) HTTP GET URL-n.jpg with If-Modified-Since
   (3-6) 304 Not Modified
         => URL-n.jpg is displayed in IFRAME
 (4) Reload of URL-main.html
   (4-1) HTTP GET URL-main.html with If-Modified-Since
   (4-2) 304 Not Modified
   (4-3) HTTP GET URL-n.jpg with If-Modified-Since
         (URL-n.jpg is Location: at step (3-4)
   (4-4) 304 Not Modified
         => URL-n.jpg is displayed in IFRAME

This is because "Reload"(LOAD_RELOAD_NORMAL) loads from session history.
But (4-3) looks as if "302 Found/Location:" response was cached.
HTTP GET for IFRAME(also FRAME) should be issued to original URL if redirected
even though "Reload", at least when cache of "302" response is not permitted.
Comment #0 is based on Web Developer's view.
Form Web developer's view, "HTTP GET URL-X.php then HTTP GET to newly
re-directed URL" is natural expectation because "onLoad" script is executed even
when "Reload".

But from Browser users's view, current flow of step (4) is very convinient.
If last redirected URL is for HTML and it includes Form, current "Reload"
process    keeps FORM element data in IFRAME such as user entered text in TEXTAREA .
And this is current design of "Reload"(and "Back Button" and so on).

What is Web Developer's expectation on "Reload" of IFRAME when redirect is
involved? 
What is Browser user's expectation on "Reload" of IFRAME when redirect is involved?
What should be done on "Reload" of IFRAME when redirect is involved? 
This is an interesting question.... Darin, biesi, what do you think we should be
reloading here?  Should we not update session history with the URI from redirects?
well, what we _should_ do imo depends on the type of redirect... for 301 Moved
Permanently we should use the new (redirected) url, for 302 Found the old one. 

see also RFC 2616, 10.3.2 and 10.3.3 (http://www.faqs.org/rfcs/rfc2616.html)
(In reply to comment #4)
> for 301 Moved Permanently we should use the new (redirected) url, for 302
Found the old one. 

It's only default of 301.
Following is brief summary of RFC on chacing for 30x.
Be carefull on caching of 30x response and reuse of Location: URL.

> 10.3.2 301 Moved Permanently
>(snip)
> This response is cacheable unless indicated otherwise.
> 10.3.3 302 Found
>(snip)
> This response is only cacheable if indicated by a Cache-Control or Expires
> header field.
> 10.3.4 303 See Other
>(snip)
> The 303 response MUST NOT be cached, but the response to the secon(redirected)
> request might be cacheable.
> 10.3.8 307 Temporary Redirect
>(snip)
> This response is only cacheable if indicated by a Cache-Control or Expires
> header field.
OK.  So how do we handle this for toplevel pages?
I don't see where caching matters? that's an impl detail of necko... while this
bug seems to be about the fact that shistory requests the wrong URL from necko.

bz: we may well handle it wrong there as well..
WADA, did you test this for non-iframes?  The summary suggests that this is an
issue for iframes only, not for all docshells.
(In reply to comment #8)
> WADA, did you test this for non-iframes?  The summary suggests that this is an
> issue for iframes only, not for all docshells.
Bug 89419 is for problem when Non-IFRAME(probably FRAME is excluded), from which
this bug spined-off.
No, that bug is about images.  What about just reloading a web page that ends up
being a 302 redirect?  Not in an iframe, just in the browser?
(In reply to comment #10)
> Not in an iframe, just in the browser?
Sorry but not tested yet.
The PHP script used in test for Bug 89419 and this bug's IFRAME case is not mine
and only JPEG case is available currently.
I'll try to create PHP script for HTML and test it on my testable site. 

[HTML case]
 (1) random.php redirects html-1.html or html-2.html or html-3.html
 (2) Access to all above and put them in cache
 (3) URL_Bar : random.php and "Enter"  
     html-N.html is displayed
     URL_Bar is changed to html-N.html
     Then all following "Reload" / "Shift+Reload" is issued to html-N.html
     In order to go to random.php, re-type, dropdown of URL_Bar etc. is required.

I've found a bug which is discussing on dynamicaly changed "Form" and "Reload",
Bug 46845 Comment #156 on frame content change by JavaScript, Bug 46845 Comment
#168 on frame content change by Servlet.

(1) Frame - frame content : Bug 46845
    - Change of frame content by Servlet
    - Change of frame content by JavaScript
(2) IFRAME - SRC URL : Bug 279048
    - Dynamicaly generated IFRAME with different SRC URI by JavaScript
    - SRC URL change by JavaScript
(3) IFRAME - URL redirect : This bug
    - Change of redirecting URL by Servlet
Corrention of comment #13. sorry for spam.
  (1) Form - form content : Bug 46845
     - Change of form content by Servlet
     - Change of form content by JavaScript
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
This may be related to the broken behavior described in bug #527897
xref bug 527897.
Depends on: 527897
This might be a security problem if an attacker catch the src attribute change during an oauth login for example.
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0a1) Gecko/20120121 Firefox/12.0a1
Build ID: 20120121040158

Steps to reproduce:


Clicked on the URL-bar once then a second time to bring the keyboard up to enter a URL.


Actual results:

After the first click the present URL http://eset-endpoint.kiev.ua/ gets selected and a list of top sites are shown but no keyboard. Clicking again opens the keyboard but the URL gets unselected and has to be deleted manually before you can start typing a new URL.


Expected results:

The URL should still be selected so it would be overwritten when you start to type
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: