Expanding on Ruben's answer which uses [HttpClient instead of WebClient][1], you can add as an extension method like this:

```cs
using System.IO;
using System.Net.Http;
using System.Threading.Tasks;

public static class Extensions
{
    public static async Task DownloadFile (this HttpClient client, string address, string fileName) {
        using (var response = await client.GetAsync(address))
        using (var stream = await response.Content.ReadAsStreamAsync())
        using (var file = File.OpenWrite(fileName)) {
            stream.CopyTo(file);
        }
    }
}
```

And then use like this:

```cs
var archivePath = "https://api.github.com/repos/microsoft/winget-pkgs/zipball/";
using (var httpClient = new HttpClient())
{
    await httpClient.DownloadFile(archivePath, "./repo.zip");
}
```

[1]: https://stackoverflow.com/questions/20530152/deciding-between-httpclient-and-webclient

I use HTTP GET that downloads a zip file in a browser, something like  https://example.com/up/DBID/a/rRID/eFID/vVID (not the exact url)

Now, when I try to do the same download in C# code(same GET method as above) for a desktop application, the zip file downloaded is not a valid archive file. When I opened this file in notepad, it was some HTML page.

I think I'm not setting some header correctly. I looked around for examples. I'd found several wrt uploads, but did not see anything for downloads. 

Code:

    HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);
    request.Method = "GET";
    request.ContentType = "application/zip";
    try
    {
        HttpWebResponse res = (HttpWebResponse)request.GetResponse();
        using (StreamReader sr = new StreamReader(res.GetResponseStream(), System.Text.Encoding.Default))
        {
            StreamWriter oWriter = new StreamWriter(@"D:\Downloads\1.zip");
            oWriter.Write(sr.ReadToEnd());
            oWriter.Close();
        }
        res.Close();
    }
    catch (Exception ex)
    {
    }

How do I download zip file in C#?

### Here's a demo in Plunker to help sort out some of these issues

* [Plunker][1]
* [stack.svg#circ][2]
* [stack.svg#rect][3]

### A URI has a couple basic components:

![URI][8]

* **Protocol** - determines how to send the request
* **Domain** - where to send the request
* **Location** - file path within the domain
* **Fragment** - which part of the document to look in

### Media Fragment URI

A fragment is simply identifying a portion of the entire file. 

Depending on the implementation of the [Media Fragment URI spec][4], it actually might be totally fair game for the browser to send along the Fragment Identifier.  Think about a streaming video, some of which has been cached on the client.  If the request is for <code>/video.ogv<b>#t=10,20</b></code> then the server can save space by only sending back the relevant portion/segment/fragment.  Moreover, if the applicable portion of the media is already cached on the client, then the browser can prevent a round trip.

### Think Round Trips, Not Requests

When a browser issues a GET Request, it does not necessarily mean that it needs to grab a fresh copy of the file all the way from the server.  If it has already has a cached version, the request could be answered immediately.

### HTTP Status Codes

* [200 - OK][6] - Got the resource and returned from the server
* [302 - Found][7] - Found the resource in the cache and not enough has changed since the previous request that we need to get a fresh copy.

### Caching Disabled

Various things can affect whether or not a client will perform caching: The way the request was issued (<kbd>F5</kbd> - soft refresh; <kbd>Ctrl</kbd> + <kbd>R</kbd> - hard refresh), the settings on the browser, any development tools that add attributes to requests, and the way the server handles those attributes.  Often, when a browser's developer tools are open, it will automatically disable caching so you can easily test changes to files.  If you're trying to observe caching behavior specifically, make sure you don't have any developer settings that are interfering with this.

When comparing requests across browsers, to help mitigate the differences between Developer Tool UI's, you should use a tool like [fiddler][5] to inspect the actual HTTP requests and responses that go out over the wire.  I'll show you both for the simple plunker example.  When the page loads it should request two different ids in the same stacked svg file.

Here are [side by side requests of the same test page in Chrome 39, FF 34, and IE 11][9]:

![Fiddler - Disable Caching][10]  
![Dev Tools - Disable Caching][11]

### Caching Enabled

But we want to test what would happen on a normal client where caching is enabled.  To do this, update your dev tools for each browser, or go to fiddler and *Rules* > *Performance* > and uncheck *Disable Caching*.

Now our request should look like this:

![Fiddler - Enable Caching][12]
![Dev Tools - Enable Caching][13]

Now all the files are returned from the local cache, regardless of fragment ID

The developer tools for a particular browser might try to display the fragment id for your own benefit, but fiddler should always display the most accurate address that is actually requested.  Every browser I tested omitted the fragment part of the address from the request:

![HTTP Request][14]

### Bundling Requests

Interestingly, chrome seems to be smart enough to prevent a second request for the same resource, but FF and IE fail to do so when a fragment is part of address.  This is equally true for SVG's and PNG's.  Consequently, the first time a page is ever requested, the browser will load one file for each time the SVG stack is actually used.  Thereafter, it's happy to take the version from the cache, but will hurt performance for new viewers.

### Final Score

**CON**: *First Trip* - SVG Stacks are not fully supported in all browsers.  One request made per instance.  
**PRO**: *Second Trip* - SVG resources will be cached appropriately 

### Additional Resources

* [simurai.com][15] is widely thought to be the first application of using SVG stacks and the article explains some browser limitations that are currently in progress
* Sven Hofmann has a great [article about SVG Stacks][16] that goes over some implementation models.
* Here's the [**source code** in Github][17] if you'd like to fork it or play around with samples
* Here's the [**official spec** for Fragment Identifiers within SVG images][18]
* Quick look at [**Browser Support** for SVG Fragments][19]

### Bugs

Typically, identical resources that are requested for a page will be bundled into a single request that will satisfy all requesting elements.  Chrome appears to have already fixed this, but I've opened bugs for FF and IE to one day fix this.

* **Chrome** - This [very old bug][20] which highlighted this issue appears to have been resolved for webkit.
* **Firefox** - [Bug Added Here][21]
* **Internet Explorer** - [Bug Added Here][22]


[1]: http://plnkr.co/edit/FvabTiApk4IfqAFLVG5M?p=preview
[2]: http://run.plnkr.co/plunks/FvabTiApk4IfqAFLVG5M/stack.svg#circ
[3]: http://run.plnkr.co/plunks/FvabTiApk4IfqAFLVG5M/stack.svg#rect

[4]: http://www.w3.org/TR/media-frags-recipes/
[5]: http://www.telerik.com/fiddler

[6]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1
[7]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3

[8]: http://i.imgur.com/wVBW6BR.png
[9]: http://imgur.com/a/XKzgp
[10]: http://i.imgur.com/SQH7YRP.png
[11]: http://i.imgur.com/S0ARYot.png
[12]: http://i.imgur.com/Gw4oPwk.png
[13]: http://i.imgur.com/5L3Tpqq.png
[14]: http://i.imgur.com/V65FbnV.png


[15]: http://simurai.com/blog/2012/04/02/svg-stacks/
[16]: http://hofmannsven.com/2013/laboratory/svg-stacking/
[17]: https://github.com/KyleMit/StackSVG

[18]: http://www.w3.org/TR/SVG/linking.html#SVGFragmentIdentifiers
[19]: http://caniuse.com/#feat=svg-fragment

[20]: https://bugs.webkit.org/show_bug.cgi?id=89983
[21]: https://bugzilla.mozilla.org/show_bug.cgi?id=1121693
[22]: https://connect.microsoft.com/IE/feedbackdetail/view/1088029/ie11-svg-fragment-downloaded-for-every-image

I have a series of overlapping questions, the intersection of which can best be asked as:

Under what circumstances does an `#` character (an anchor) in a URL trigger an HTTP fetch, in the context of either an `<a href` or an `<img src` ? 

Normally, should:

    http://foo.com/bar.html#1

and

    http://foo.com/bar.html#2

require two different HTTP fetches?  I would think the answer should definitely be NO.

**More specific details:**

The situation that prompted this question was my first attempt to experiment with [**SVG stacking**][1] - a technique where multiple icons can be embedded within a single `svg` file, so that only a single HTTP request is necessary.  Essentially, the idea is that you place multiple SVG icons within a single file, and use CSS to hide all of them, except the one that is selected using a CSS `:target` selector.

You can then select an individual icon using the `#` character in the URL when you write the `img` element in the HTML:

    <img 
        src="stacked-icons.svg#icon3" 
        width="80" 
        height="60" 
        alt="SVG Stacked Image" 
    />

When I try this out on Chrome it works perfectly.  A single HTTP request is made, and multiple icons can be displayed via the same `svg` url, using different anchors/targets.

However, when I try this with Firefox (28), I see via the Console that *multiple* HTTP requests are made - one for each svg URL!  So what I see is something like:

    GET http://myhost.com/img/stacked-icons.svg#icon1 
    GET http://myhost.com/img/stacked-icons.svg#icon2 
    GET http://myhost.com/img/stacked-icons.svg#icon3 
    GET http://myhost.com/img/stacked-icons.svg#icon4
    GET http://myhost.com/img/stacked-icons.svg#icon5

...which of course defeats the purpose of using SVG stacking in the first place.  

Is there some reason Firefox is making a separate HTTP request for *each* URL instead of simply fetching `img/stacked-icons.svg` once like Chrome does? 

This leads into the broader question of - what rules determine whether an `#` character in the URL should trigger an HTTP request?

  [1]: http://hofmannsven.com/2013/laboratory/svg-stacking/