Embedio: Supporting System.Net.Http.HttpRequestMessage

Created on 10 Jun 2019  路  5Comments  路  Source: unosquare/embedio

Is your feature request related to a problem? Please describe.
I had a module which accept System.Net.Http.HttpRequestMessage and returns System.Net.Http.HttpResponseMessage.

I wish embedio supports converting to and from these objects for more compatibility,

Describe the solution you'd like
Having two methods such as ToHttpRequestMessage and FromHttpResponseMessage

Describe alternatives you've considered
EmbedIO requests based on Unosquare.Labs.EmbedIO.IHttpRequest. Why not based on .NET HttpRequestMessage! I am not sure, maybe at the time it is designed it didn't exist or maybe the .NET doesn't meet the requirement!

enhancement help wanted wontfix

Most helpful comment

Hello @madnik7.

I totally agree. If we could use HttpRequestMessage and HttpResponseMessage, we could also use derive a client class from HttpMessageInvoker to test EmbedIO. Heck, we could test EmbedIO using Flurl.Http!

That said, I have already tried and failed at that. The exact details escape me at the moment, but I remember I needed access to some internal methods and/or fields. I could have used reflection, of course, but the resulting code would have been too "hacky" and fragile.

I could try again, of course. Maybe those classes have already been unified at a source level between .NET Framework, .NET Core, and Mono; maybe they are stable enough that using reflection to gain access to some internal stuff is not the deadly sin it seemed some time ago.

All 5 comments

Hello @madnik7.

I totally agree. If we could use HttpRequestMessage and HttpResponseMessage, we could also use derive a client class from HttpMessageInvoker to test EmbedIO. Heck, we could test EmbedIO using Flurl.Http!

That said, I have already tried and failed at that. The exact details escape me at the moment, but I remember I needed access to some internal methods and/or fields. I could have used reflection, of course, but the resulting code would have been too "hacky" and fragile.

I could try again, of course. Maybe those classes have already been unified at a source level between .NET Framework, .NET Core, and Mono; maybe they are stable enough that using reflection to gain access to some internal stuff is not the deadly sin it seemed some time ago.

I also believe that reflection should not be used in this scenario unless these classes already lack something important which it may lead us that they haven't designed them properly.

Well, they _are_ designed properly, _for their intended use_.

Please remember that we're talking about the same people that wrote an internal class providing all HTTP header names as constants. Because, you know, who might ever need them outside Microsoft? 馃

With EmbedIO v3.0 (currently in preview) the new EmbedIO.Testing package provides a HttpClient derived class that works with TestServer. So at least testing can be performed with standard HttpRequestMessage and HttpResponseMessage.

This issue remains open because it refers to overall utilization of HttpRequestMessage and HttpResponseMessage, not just for testing; nonetheless, I thought it would be nice to know that _some_ advancement has taken place.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rocketraman picture rocketraman  路  7Comments

simohr picture simohr  路  5Comments

Joe118 picture Joe118  路  6Comments

chyyran picture chyyran  路  6Comments

felixerdy picture felixerdy  路  7Comments