Closed Bug 196871 Opened 21 years ago Closed 20 years ago

Referrer downloads cause bad data page or invalid html on shift-click on link


(SeaMonkey :: UI Design, defect)

Windows XP
Not set


(Not tracked)



(Reporter: oddball, Assigned: Biesinger)





(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b; MultiZilla vundefinedundefined) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b; MultiZilla vundefinedundefined) Gecko/20030210

The link to the file uses a a java referrer mechanism. IE downloads the file
correctly. Left clicking the file in Mozilla causes a page of garbage to load or
if you shift-click the link it downloada an HTML file with the following
information in it.

"Unauthorized download

We're sorry, but this downlod request cannot be authorized. There could be
several reasons for this:

1) You clicked on a link on a site that is not part of the Doom9 domains. In
this case the URL in your browser would not contain or We
do not allow that kind of external hotlinking. This site creates a great deal of
traffic and it's hard to find a good hosting. We will not provide the bandwith
for other sites, too so that they can have a great software archive without
having to host and pay for it. Please visit and you can download all
the files you want.

2) You're using a download manager. Download managers usually offer to search
for alternative download locations. While this is nice for the user, it's bad
for the webmaster because it could be that a download which originated on
another site could theoretically still be downloaded from this site, without
anybody knowing. But there's a solution to this problem:

Set up your download manager to send a HTTP referer, and when you click on a
link on the Doom9 site the download will be authorized. Here's how you can do
this in Getright:

Go to Getright Configuration, under Advanced/Protocol check Send "Referer" in
HTTP Request and then select Generated from the download URL.

The setup should be similar for other download managers.

3) Your browser did not send a referer. This normally happens if you right click
on a link and select save-as, or if you copy and paste a link into a new browser
window and press Enter. It may also be that your browser is set up to not send
any referer, though I did not find any such option in the browser I'm using
(IE6). Unfortunately we must test for empty referer or we still have the
download manager problem mentioned in 2). But left clicking on a link works just
fine and has been tested in IE6, Netscape 6, Opera6 and Mozilla 1.0.

Some software firewalls, for instance the Norton Personal Firewall (which is
also part of Norton Internet Security) or ZoneAlarm remove the referer from HTTP
requests which will block any downloads on any site that does a referer check.
Hence such options should always be turned off. In Norton you have to go to the
Privacy Settings and disable browser privacy (which doesn't really protect your
privacy anyway as your IP address will always be logged regardless of that
setting), in ZoneAlarm you have to go to Privacy -> Cookie Control -> Custom and
uncheck "remove private header information".

Software like AdSubstract also blocks the referer and makes downloads impossible.

We're sorry for any inconvenience this may cause and hope you understand our
reasons for doing so. Bandwith doesn't come cheap and we have to do all we can
to keep the bandwith usage (roughly 600GB a month these days) down."

Reproducible: Always

Steps to Reproduce:
1. Click on link to download rar
2. Shift click on link to download HTML

Actual Results:  
See above

Expected Results:  
To download rar file to hard disk. This does not occur.
Linux 2003031105
Go to then find "Media Player Classic" 

Clicking the Link:
Causes a HTTP GET Request w/ a Referer of
Then the Server responds with HTTP/1.1 200 with a Content type:text/plain
mozilla downloads the rar file and displays it as a plain text file

Right clicking the link:
Causes a HTTP HEAD Request w/o a Referer 
Then the Server responds with HTTP/1.1 302 with a Location of
mozilla go and retrives w/o problems.

Adding a Referer to the HEAD request would fix this so you can atleast right
click and save the file.
This is a dup of us not sending the referrer on save operations (clicking on the
link is not a save operation -- different codepath).
Depends on: 160454
Whiteboard: DUPEME
that would be bug 170722 but the bug is marked fixed and it's still not working.
Any hints Boris ?
The back end now sends a referrer if its given one.  The Save As front end still
needs to give it one.
Unless I've missed something, this is a dupe of bug 188253.

*** This bug has been marked as a duplicate of 188253 ***
Closed: 20 years ago
Resolution: --- → DUPLICATE
The page descriptor is something that lets you get the page data from the cache.

The referrer is something you only need if you're going to end up hitting the

The two are unrelated....
Resolution: DUPLICATE → ---
Sorry, I didn't realize that. I was following a trail of bugs and saw that that
one was spun off of bug 170722 (which does deal with referrers) and I guess I
made a bad assumption.
->XP Apps
Assignee: asa → jag
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: asa → pawyskoczka
Bug 236194 is the same bug for Firefox.  It has a simple Firefox-specific patch.
taking. bug 160454 might make this a bit easier to fix, but this is doable
either way.
Assignee: jag → cbiesinger
No longer depends on: 160454
Attached patch patchSplinter Review
who knows... maybe this fixes some of the problems with "save link target as"
Attachment #143068 - Flags: superreview?(bzbarsky)
Attachment #143068 - Flags: review?(
well that was pretty badly worded. I meant some of the problems that were blamed
on HEAD before...
Target Milestone: --- → mozilla1.7beta
Comment on attachment 143068 [details] [diff] [review]

sr=bzbarsky, but I _really_ wish firefox hadn't forked this code... :(
Attachment #143068 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 143068 [details] [diff] [review]

>+    var refer = getReferrer(document);
Some naming consistency would be nice, var referrer perhaps?
I assume that unsuitable referrers will get screened out at some point?
Attachment #143068 - Flags: review?( → review+
(In reply to comment #14)
> Some naming consistency would be nice, var referrer perhaps?

ok, I'll change that

> I assume that unsuitable referrers will get screened out at some point?

yes, nsHttpChannel does that.

Checking in resources/content/contentAreaUtils.js;
/cvsroot/mozilla/xpfe/communicator/resources/content/contentAreaUtils.js,v  <--
new revision: 1.104; previous revision: 1.103
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Question: Is a referrer sent if I do a "save link target as" with this pref?

user_pref("network.http.sendRefererHeader", 1);
// 0=don't send any, 1=send only on clicks, 2=send on image requests as well

I haven't personally tried, but examining the code, it looks as if the
preference is respected.
(In reply to comment #18)
> I haven't personally tried, but examining the code, it looks as if the
> preference is respected.

Yes it is. I tried it with The only (nothing to do with this bug)
thing is, if you do a shift+click to download you will always get a .rar.html or
.zip.html served (wrong extension).
Product: Core → Mozilla Application Suite
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.