22

I have a whole bunch of web services each with several web methods. The consumers of these services are varied and many. I want to augment each of these web methods with an extra optional parameter (Int64 or Int32) but adding new methods with this extra (optional parameter) is a lot of work and getting the clients to use the new methods will be even more time consuming.

So I was wondering if I could allow the clients that wanted to take advantage of the new feature that this param provides could pass this Int in the HTTP header or some other way.

So the first question is can I pass an int in the HTTP header? If so, how would one do that in C#/ASP.NET?

Otherwise, what other suggestions do you have for tackling this problem?

Guy
  • 65,082
  • 97
  • 254
  • 325

8 Answers8

13

Its a bit unorthodox and I'm sure some purists would be upset at the idea (the headers should only be used for the transport of the message, and should not contain the semantics of the message).

Practically its doable, but you want to be sure all your clients can add these headers. If your clients are using tools to call the web methods rather than generating the HTTP requests themselves (which I'd hope is the case) then there's a real chance this is a problem.

Why is it so hard to add these additional overloads of the methods?

Prashant Pokhriyal
  • 3,727
  • 4
  • 28
  • 40
Frank Schwieterman
  • 24,142
  • 15
  • 92
  • 130
  • 9
    Yes its unorthodox to WS-*, but I think RESTful type people (RESTafarians?) would be cool with it ;) – Michael Neale Feb 19 '09 at 01:32
  • 8
    I'm fairly certain RESTful types would expect input parameters to be in the request path or request body. – Frank Schwieterman Feb 19 '09 at 05:02
  • 6
    I've been bit by this due to mobile networks. At one job, we did some hmac'ing of our custom headers to validate the data at the other end. On some of the UK networks, their proxies did some kind of header strip/reconstruction during which an extra space was removed from our header. Was not a good time solving that one. – Error 454 Feb 21 '13 at 01:57
11

Yes it is allowed - but note that it may cut off the ability to use proxies and sometimes http aware firewalls (they tend to inspect and rewrite headers).

Michael Neale
  • 19,248
  • 19
  • 77
  • 109
5
Request.Headers.Add("headername", "headervalue");
Response.Headers.Add("headername", "headervalue");
शेखर
  • 17,412
  • 13
  • 61
  • 117
Demi
  • 6,147
  • 7
  • 36
  • 38
2

I've used this concept once to handle logout redirect for ajax calls in an intranet web application (nothing related to webservice).

it was my best solution at hand, but as some other have said it depends if you can push the constraint to clients to treat theses headers for your purpose.

Definitely not a thing you would want to do by default.

smoothdeveloper
  • 1,972
  • 18
  • 19
2

FROM RFC!

You really can, now it is supported by the new RFC Standards,

Really helps when you want to GET from your API but still want GET pure nativity(no body in GET)

For a simplified read, check out Mozilla Explanation

emanuel sanga
  • 815
  • 13
  • 17
1

You can, but you have to define a Header, then set its value. Like in the HttpWebRequest you can add any header, as long as its not one of the reserved ones.

Mike_G
  • 16,237
  • 14
  • 70
  • 101
1

Note that while it's fine to consume custom headers in ASP.NET it's not always possible to produce custom headers in ASP.NET. You can only do this if you're running ASP.NET integrated mode (i.e. IIS 7.0).

John Leidegren
  • 59,920
  • 20
  • 131
  • 152
1

You can, but this defeats the whole purpose of using webservices in the first place. Similar to the saying that each formula in a popular science books reduces the audience to a half, each quick hack increasing the complexity of the interface will mean a lot of trouble in the future.

paavo256
  • 181
  • 3