From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 BuildID: Netscape6 We are using Weblogic server 4.03 and Netscape Enterprise Server 3.6 for website hosting. A servlet on site1 does a url sendredirect to site2. Site2 then checks the HTTP Referer. In this case, the Referer should be Site1. However, there is no Referer information in the HTTP header at all when we use Netscape 6.1 browser. The Referer did show up if we use Netscape 4.x or 6.0 browser. Reproducible: Always Steps to Reproduce: 1.Access site1 in Netscape6.1 browser 2.Site1 has a Java servlet does a url sendredirect to site2 3.Site2 Java servlet request object prints out the HTTP header Actual Results: There is no Referer information in HTTP header Expected Results: Should display Referer:site1

Are you dealing with a secure server? This is probably bug 89995. Please test with a recent Mozilla build -- NS6.1 is pretty old.

Yes, We are using secure servers. Both of our sites (site1 and site2) are secure servers. Shouldn't referers be sent from one site to the other if both sites are secure sites? I am using Netscape6.1, the latest official release. I don't have this problem in NS4.x and 6.0. Is this a bug of NS6.1? Will the future release fix this problem? Thanks.

> Shouldn't referers be sent from one site to the other if both sites > are secure sites? Yes if they are on the same server. > I am using Netscape6.1, the latest official release. The latest official Mozilla release is Mozilla 0.9.4. Netscape 6.1 is based on the rather old Mozilla 0.9.2 > Will the future release fix this problem? This problem should be fixed in current nightly builds and in 0.9.4 ccing people from bug 89995 to discuss what should happen for two different secure servers.

We decided that we would not send referer to different hosts. Should we revisit this?

I believe that would introduce a problem with going from a GET url to a different site by accident and the Referer header being sent

dupping to 89995 *** This bug has been marked as a duplicate of 89995 ***

Verified dupe.