When I try to add a HTTP header key/value pair on a WebRequest
object, I get the following exception:
This header must be modified using the appropriate property
I've tried adding new values to the Headers
collection by using the Add() method but I still get the same exception.
webRequest.Headers.Add(HttpRequestHeader.Referer, "http://stackoverflow.com");
I can get around this by casting the WebRequest object to a HttpWebRequest and setting the properties such as httpWebReq.Referer ="http://stackoverflow.com"
, but this only works for a handful of headers that are exposed via properties.
I'd like to know if there's a way to get a finer grained control over modifying headers with a request for a remote resource.
I'm using just:
I ran into this problem with a custom web client. I think people may be getting confused because of multiple ways to do this. When using
WebRequest.Create()
you can cast to anHttpWebRequest
and use the property to add or modify a header. When using aWebHeaderCollection
you may use the.Add("referer","my_url")
.Ex 1
Ex 2
If you need the short and technical answer go right to the last section of the answer.
If you want to know better, read it all, and i hope you'll enjoy...
I countered this problem too today, and what i discovered today is that:
the above answers are true, as:
1.1 it's telling you that the header you are trying to add already exist and you should then modify its value using the appropriate property (the indexer, for instance), instead of trying to add it again.
1.2 Anytime you're changing the headers of an
HttpWebRequest
, you need to use the appropriate properties on the object itself, if they exist.Thanks FOR and Jvenema for the leading guidelines...
But, What i found out, and that was the missing piece in the puzzle is that:
2.1 The
WebHeaderCollection
class is generally accessed throughWebRequest
.Headers orWebResponse
.Headers. Some common headers are considered restricted and are either exposed directly by the API (such as Content-Type) or protected by the system and cannot be changed.The restricted headers are:
Accept
Connection
Content-Length
Content-Type
Date
Expect
Host
If-Modified-Since
Range
Referer
Transfer-Encoding
User-Agent
Proxy-Connection
So, next time you are facing this exception and don't know how to solve this, remember that there are some restricted headers, and the solution is to modify their values using the appropriate property explicitly from the
WebRequest
/HttpWebRequest
class.Edit: (useful, from comments, comment by user Kaido)
All the previous answers describe the problem without providing a solution. Here is an extension method which solves the problem by allowing you to set any header via its string name.
Usage
Extension Class
Scenarios
I wrote a wrapper for
HttpWebRequest
and didn't want to expose all 13 restricted headers as properties in my wrapper. Instead I wanted to use a simpleDictionary<string, string>
.Another example is an HTTP proxy where you need to take headers in a request and forward them to the recipient.
There are a lot of other scenarios where its just not practical or possible to use properties. Forcing the user to set the header via a property is a very inflexible design which is why reflection is needed. The up-side is that the reflection is abstracted away, it's still fast (.001 second in my tests), and as an extension method feels natural.
Notes
Header names are case insensitive per the RFC, http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
Basically, no. That is an http header, so it is reasonable to cast to
HttpWebRequest
and set the.Referer
(as you indicate in the question):Anytime you're changing the headers of an
HttpWebRequest
, you need to use the appropriate properties on the object itself, if they exist. If you have a plainWebRequest
, be sure to cast it to anHttpWebRequest
first. ThenReferrer
in your case can be accessed via((HttpWebRequest)request).Referrer
, so you don't need to modify the header directly - just set the property to the right value.ContentLength
,ContentType
,UserAgent
, etc, all need to be set this way.IMHO, this is a shortcoming on MS part...setting the headers via
Headers.Add()
should automatically call the appropriate property behind the scenes, if that's what they want to do.