622579 - View Page Source says "The page isn't redirecting properly" and does not show page's source

Status: RESOLVED INVALID

(Core :: Networking: Cookies, defect, P5)

Description

[Stefan]

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20100101 Firefox/4.0b9pre

Page source does not show the source of the page

Reproducible: Always

Steps to Reproduce:
1. open URL
2. View | Page Source
3.
Actual Results:  
"The page isn't redirecting properly"

Expected Results:  
Show page source.

Comment 1

[Ed Morley [:emorley]]

Confirmed with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110103 Firefox/4.0b9pre ID:20110103030359

This behaviour only seems to occur if "accept 3rd party cookies" is unticked in privacy prefs.

ie:
unticked = page loads fine in browser, but view source broken
ticked = page loads fine in browser & view source works fine

Comment 2

[Ed Morley [:emorley]]

Regression, works fine with 3.6.13.

Last good nightly: 2010-05-03 
First bad nightly: 2010-05-04

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=83c887dff0da&tochange=d6bb0f9e9519

Not sure what in that range may have caused it though.

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

Flipping html5.enable seems to Show ("true")/Hide ("false") the Issue besides the network.cookie.cookieBehavior "0"/"1" (3rd Party Cookies) Setting.

Comment 4

[Johnny Stenback (:jst)]

Henri, can you look? Not sure what triggers this, view-source generally works, but this bug claims there's a case where it doesn't.

Not blocking on this for now, but if this turns out to be a wide spread issue, please renominate.

Comment 5

[Henri Sivonen (:hsivonen)]

 * An nsViewSourceChannel really gets created initially.
 * nsViewSourceChannel inherits from nsHttpChannel, which processes a cached redirect.
 * The redirects go into an asynchronous redirect loop.
 * The site indeed has a redirect loop that can be verified with http://web-sniffer.net/?url=http%3A%2F%2Fnol.hu%2Findex.html&gzip=yes&http=1.1

I think the interesting question is why we don't see the redirect loop warning when loading the page normally.

Comment 6

[Henri Sivonen (:hsivonen)]

When simply browsing to the page, there is a redirect loop, but when the redirects come back to the URL that the loop started with (http://nol.hu/index.html), the server breaks the loop by responding with 200 OK.

However, the initial request to http://nol.hu/index.html that the gets a 302 Found response and the second request to http://nol.hu/index.html are identical requests (same headers including the Cookie header) according to Live HTTP Headers.

Comment 7

[Henri Sivonen (:hsivonen)]

Flipping html5.enable at different shows that it matters if the HTML5 parser was used for the normal page load before viewing source. Presumably, the parser affects the cache entry.

Comment 8

[Henri Sivonen (:hsivonen)]

Honza, do you have advice what part of the networking code I should be looking at in order to see why the cache entry for the original load becomes different so that it doesn't get used when viewing source?

Comment 9

[Honza Bambas (:mayhemer)]

(In reply to comment #8)
> Honza, do you have advice what part of the networking code I should be looking
> at in order to see why the cache entry for the original load becomes different
> so that it doesn't get used when viewing source?

I have to install Flash on my dev machine to try to reproduce.  I can do it, however I dislike it.

Comment 10

[Stefan]

Flash? I can reproduce it without flash here.

Comment 11

[Honza Bambas (:mayhemer)]

Sorry, I got lost between all the logging bugs.  Comment 9 doesn't belong here.

(In reply to comment #8)
> Honza, do you have advice ...

We end up with NS_ERROR_REDIRECT_LOOP when loading the page for view-source.

This is log snip when loading the page normally in a browser tab, filtering for Cookie, redirecting, etc.:

  GET /index.html HTTP/1.1
  Host: nol.hu
redirecting to: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html [redirection-limit=20]
  GET /login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html HTTP/1.1
  Host: sso.nol.hu
  Cookie: PHPSESSID=pnfubi91k2e672ggc54effpjk7
redirecting to: http://nol.hu/index.html?noltoken=TVBY3QoAAnMAAUvNZbQAAAAL4d5058dd [redirection-limit=19]
  GET /index.html?noltoken=TVBY3QoAAnMAAUvNZbQAAAAL4d5058dd HTTP/1.1
  Host: nol.hu
  Cookie: PHPSESSID=pnfubi91k2e672ggc54effpjk7; nol_ctoken=TVBY3QoAAnMAAUvNZbQAAAAL4d5058dd
redirecting to: http://nol.hu/index.html [redirection-limit=18]
  GET /index.html HTTP/1.1
  Host: nol.hu
  Cookie: PHPSESSID=pnfubi91k2e672ggc54effpjk7; nol_ctoken=TVBY3QoAAnMAAUvNZbQAAAAL4d5058dd



This is a log snip when we load for view-source:

  GET /index.html HTTP/1.1
  Host: nol.hu
redirecting to: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html [redirection-limit=20]
nsHttpChannel::ReadFromCache [this=c2879b8] Using cached copy of: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html
redirecting to: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7 [redirection-limit=19]
nsHttpChannel::ReadFromCache [this=941b758] Using cached copy of: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7
redirecting to: http://nol.hu/index.html [redirection-limit=18]
redirecting to: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html [redirection-limit=17]
nsHttpChannel::ReadFromCache [this=941b758] Using cached copy of: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html
redirecting to: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7 [redirection-limit=16]
nsHttpChannel::ReadFromCache [this=c2879b8] Using cached copy of: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7
redirecting to: http://nol.hu/index.html [redirection-limit=15]
nsHttpChannel::ReadFromCache [this=941b758] Using cached copy of: http://nol.hu/index.html
redirecting to: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html [redirection-limit=14]
nsHttpChannel::ReadFromCache [this=c2879b8] Using cached copy of: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html
redirecting to: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7 [redirection-limit=13]
nsHttpChannel::ReadFromCache [this=941b758] Using cached copy of: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7
redirecting to: http://nol.hu/index.html [redirection-limit=12]
nsHttpChannel::ReadFromCache [this=c2879b8] Using cached copy of: http://nol.hu/index.html
redirecting to: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html [redirection-limit=11]
nsHttpChannel::ReadFromCache [this=941b758] Using cached copy of: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html
redirecting to: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7 [redirection-limit=10]
nsHttpChannel::ReadFromCache [this=c2879b8] Using cached copy of: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7
redirecting to: http://nol.hu/index.html [redirection-limit=9]
nsHttpChannel::ReadFromCache [this=941b758] Using cached copy of: http://nol.hu/index.html
redirecting to: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html [redirection-limit=8]
nsHttpChannel::ReadFromCache [this=c2879b8] Using cached copy of: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html
redirecting to: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7 [redirection-limit=7]
nsHttpChannel::ReadFromCache [this=941b758] Using cached copy of: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7
redirecting to: http://nol.hu/index.html [redirection-limit=6]
nsHttpChannel::ReadFromCache [this=c2879b8] Using cached copy of: http://nol.hu/index.html
redirecting to: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html [redirection-limit=5]
nsHttpChannel::ReadFromCache [this=941b758] Using cached copy of: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html
redirecting to: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7 [redirection-limit=4]
nsHttpChannel::ReadFromCache [this=c2879b8] Using cached copy of: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7
redirecting to: http://nol.hu/index.html [redirection-limit=3]
nsHttpChannel::ReadFromCache [this=941b758] Using cached copy of: http://nol.hu/index.html
redirecting to: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html [redirection-limit=2]
nsHttpChannel::ReadFromCache [this=c2879b8] Using cached copy of: http://sso.nol.hu/login/index.php?backurl=http%3A%2F%2Fnol.hu%2Findex.html
redirecting to: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7 [redirection-limit=1]
nsHttpChannel::ReadFromCache [this=941b758] Using cached copy of: http://nol.hu/index.html?noltoken=TVBetwoAAn0AAVhjs6EAAAAp4d505eb7



As you can see, we are not sending any cookies with the view-source initiated requests.  Therefor we loop in redirect.

I can see following error during every request made by view-source:

WARNING: NS_ENSURE_TRUE(isFileURI) failed: file d:/mozilla/mozilla-central/_obj-browser-debug/content/base/src/../../../../content/base/src/ThirdPartyUtil.cpp, line 94 [1]

Stack trace:

>	xul.dll!ThirdPartyUtil::GetBaseDomain(nsIURI * aHostURI=0x0c1c8db8, nsCString & aBaseDomain={...})  Line 94	
 	xul.dll!ThirdPartyUtil::IsThirdPartyWindow(nsIDOMWindow * aWindow=0x0c1c9b60, nsIURI * aURI=0x0c289dd8, int * aResult=0x001ea604)  Line 172 + 0x15 bytes	
 	xul.dll!ThirdPartyUtil::IsThirdPartyChannel(nsIChannel * aChannel=0x0c2b4bec, nsIURI * aURI=0x0c289dd8, int * aResult=0x001ea604)  Line 310 + 0x24 bytes	
 	xul.dll!nsCookieService::GetCookieStringCommon(nsIURI * aHostURI=0x0c289dd8, nsIChannel * aChannel=0x0c2b4bec, bool aHttpBound=true, char * * aCookie=0x001ea6cc)  Line 1448	
 	xul.dll!nsCookieService::GetCookieStringFromHttp(nsIURI * aHostURI=0x0c289dd8, nsIURI * aFirstURI=0x00000000, nsIChannel * aChannel=0x0c2b4bec, char * * aCookie=0x001ea6cc)  Line 1432	
 	xul.dll!mozilla::net::HttpBaseChannel::AddCookiesToRequest()  Line 1260 + 0x50 bytes	
 	xul.dll!nsHttpChannel::AsyncOpen(nsIStreamListener * listener=0x0c289d4c, nsISupports * context=0x00000000)  Line 3631	
 	xul.dll!nsViewSourceChannel::AsyncOpen(nsIStreamListener * aListener=0x0c2b5120, nsISupports * ctxt=0x00000000)  Line 233 + 0x3c bytes	


aHostURI is nsSimpleNestedURI "about:blank" having mBaseURI nsStandardURL with "chrome://global/content/viewSource.xul"

aBaseDomain is empty.


[1] http://mxr.mozilla.org/mozilla-central/source/content/base/src/ThirdPartyUtil.cpp#94

Uf..

Comment 12

[Honza Bambas (:mayhemer)]

Probably get aBaseDomain from inner URI of "chrome:" nested URIs?

Comment 13

[Honza Bambas (:mayhemer)]

(In reply to comment #12)
> Probably get aBaseDomain from inner URI of "chrome:" nested URIs?

..the inner URI is moz-safe-about:blank in that method.

We are trying to get the base domain from URI of the containing window that results here to about:blank -> chrome:/viewsource (GetURIFromWindow returns that URI) here:

http://hg.mozilla.org/mozilla-central/annotate/94d61f41b3b5/content/base/src/ThirdPartyUtil.cpp#l167

CC'ing Dan Witt as author of that code.

Comment 14

[[e-mail]]

And you want it to be the content URI, right?

I'm guessing that aWindow in IsThirdPartyWindow is chrome, rather than content. Which probably means that the associated window wasn't set right on the loadcontext for the channel:

http://hg.mozilla.org/mozilla-central/annotate/94d61f41b3b5/content/base/src/ThirdPartyUtil.cpp#l278

... which could easily be the case, if we don't actually have a window for the load (since we're not rendering the content anywhere). I'm not sure if this is true; bz would know.

In which case, you just want to set forceAllowThirdPartyCookie on the channel...

http://hg.mozilla.org/mozilla-central/annotate/94d61f41b3b5/content/base/src/ThirdPartyUtil.cpp#l236

Comment 15

[Stefan]

It appears rather questionable that there is a codepath from "view source" to an actual HTTP request. I would have expected that possible side effects of "view source" are confined to the browser's RAM.

Comment 16

[Henri Sivonen (:hsivonen)]

(In reply to comment #11)
> We end up with NS_ERROR_REDIRECT_LOOP when loading the page for view-source.

Indeed, but why doesn't view source load from the cache entry in this case when the HTML5 parser is enabled during the initial page load (as noted in comment 7)?

Comment 17

[Honza Bambas (:mayhemer)]

When HTML5 parser is used (html5.enable = true), nsHttpChannel handling the view source request doesn't get read access on the cache entry.  It means it has not been found in the cache and is not used for view source.

Comment 18

[Honza Bambas (:mayhemer)]

And it happens because the page does an image request with an empty src attribute.  Load of that image fails and dooms the cache entry.  Therefor view-source doesn't find it later.

So, the problem is not in the parser.

The fix should then be to force 3rd party cookies on the view-source request.

Comment 19

[Henri Sivonen (:hsivonen)]

(In reply to comment #18)
> And it happens because the page does an image request with an empty src
> attribute.  Load of that image fails and dooms the cache entry.

Thanks for investigating this!

> The fix should then be to force 3rd party cookies on the view-source request.

OK. Moving over to Networking.

Comment 20

[Boris Zbarsky [:bzbarsky]]

> The fix should then be to force 3rd party cookies on the view-source request.

That's generally a privacy leak if third-party cookies are disabled, no?

Why does the third-party security check fail again?

Comment 21

[[e-mail]]

It fails because we're trying to determine the toplevel load URI, which derives from a docshell heirarchy, but in this case we don't have one and we just get a chrome:// URI back. Which is exactly the intended case: if you really want cookies for such loads, you have to explicitly state so by forcing the flag. And doing that should raise the question you just posed :)

In this case, whatever third party cookies are associated with the page have already been set/sent when loading the page initially, which presumably has happened. And asking to view source is a user-initiated act, not something the browser or an extension is sneakily doing. So it's of dubious value to block it.

Ideally, we wouldn't fire a load at all under any circumstances, but we do, so here we are.

Comment 23

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 24

[Andrea Marchesini [:baku]]

This bug cannot be reproduced anymore.