3

I'm having an implementation of DelegatingHandler which basically take a request and address it to another server (http://localhost:9999/test/page.php --> http://otherSite.com/test/page.php ).

Following my question here, I now have to read the result of the page and edit it a little bit:

protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
{
    string url = request.RequestUri.PathAndQuery;
    UriBuilder forwardUri = new UriBuilder(_otherWebSiteBase);
    forwardUri.Path = url;

    HttpRequestMessage newRequest = request.Clone(forwardUri.Uri.ToString());

    HttpResponseMessage responseMessage = await _client.SendAsync(newRequest);
    //HERE: How to read the responseMessage.Content in string?
    return responseMessage;
}

I'm trying to read the content of the message, change some parts of it(basically change all http://otherSite.com into http://localhost:9999 ) and then return it.

The issues that I'm facing:

string content =await responseMessage.Content.ReadAsStringAsync();
  1. Doesn't returns me anything that is readeable(I'm not sure, but I've the impression it's maybe because of the compression?)
  2. Is there a way to replace the content of the message?
J4N
  • 19,480
  • 39
  • 187
  • 340

1 Answers1

0

I'm trying to understand this a little better. Are you simply looking to make all requests that go to that address get redirected to another address? Given that you're putting this in the delegating handler, I'm imagining this is being run for every incoming request.

If that's the case, I don't really believe this is the location to write this code. There are two other places that I think provide a cleaner solution.

In the web server:

You seem to be recreating the idea of a Reverse Proxy (https://en.wikipedia.org/wiki/Reverse_proxy) where you want one server to simply direct requests to another without the client knowing about the change. You can make this modification on the server itself. If you're using IIS, there are guides to use IIS plugins like Application Request Routing to achieve this ( http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing ). Other web servers also have their own solutions but I have not personally tried them.

On the route itself

On whatever Web API route would be responding to this request, you can use http status codes to tell the browser to redirect the request elsewhere.

The 3xx series were specifically made to solve this kind of problem: http://www.restapitutorial.com/httpstatuscodes.html


That said, if you still want to use the approach in the original question, you need to ensure that there is a Media-Type Formatter for the data type that is being returned. By default, Web API will only attempt to use formatters for JSON, XML, and Form-url-encoded data. If you are returning anything else, you'll need to do a little more work ( http://www.asp.net/web-api/overview/formats-and-model-binding/media-formatters ) to get the data back to manipulate it.

Community
  • 1
  • 1
Soriin
  • 36
  • 1
  • 3
  • Thank you for your appreciated answer! **For your first point**: The concept is a little bit like what you're describing, except: The proxy will be on the client side, and, I've to modify some part of the content. Additionally, the clients will be accessing it by a different hostname. The reason behind this is: The client should have the choice to directly access the real website, AND, the c# application that is hosting the web api should be able to use the web client to send request with the same session. – J4N Jun 19 '15 at 05:22
  • **For your second point**: I'm not sure to fully understand what will be the result of using those status code, but I feel I will not be able to edit the content of the return and that the user will be redirected to the real website, which isn't expected. **For your third point**: I'm expecting full old plain html(I've not the code here, but I'm pretty sure it was `text/html` but the content was not readeable(some unrecognized chars). I saw gzip in the response header, so do I need to unzip it first? Or indicate that I don't support it? – J4N Jun 19 '15 at 05:26
  • @J4N If compression is the key point, then http://www.netomatix.com/development/httpcontentencoding.aspx is a good reference on the Accept-Encoding http header and the https://msdn.microsoft.com/en-us/library/system.io.compression.gzipstream%28v=vs.110%29.aspx Class will enable you to decompress the content. You can do a quick test by disabling compression in the Header and seeing what result you get back but ideally you'd like to leave compression on for performance reasons. – Soriin Jun 19 '15 at 18:17