We are dealing with some financial institutions that send us requests encoded in ISO-8859-1. They post back to us during an authentication flow, where the query string is ISO-8859-1 encoded (some characters in the request query use Å, ä etc). How do you configure ASP.NET Core API controllers to correctly give us the decoded parameters? The default (UTF-8) obviously does not work correctly. Previous API such as
HttpUtility.UrlDecode(request.Value, System.Text.Encoding.GetEncoding(28591))
seem to have vanished (or are not yet there) in .NET Core RTM.
Our workaround is to create a separate util lib with the above encoding call that cannot target .NET Core.
Is there a way to configure request encoding in web.config or any other proper way of dealing with this?
Related
ASP.NET Core 7 preview 6 just introduced Output caching which caches the endpoint output. However ASP.NET already has Response caching which seems to already provide the same feature.
What is the difference between the two and when should one be used and when should the other be used?
I was looking for aswers and trying to understand the differences between both, and really took a huge amount of time to understand the diferences between the two, and when (or not) to use each other.
As of November 2022 .Net 7 has been released, but the documentation is not very clear about the differences between them. The documentation and all videos only talk about the OutputCache as a replacement for the ResponseCache.
Also searching for OutputCache, it comes up with a lot of results from the old AspNet (Full framework) MVC 5.
So let´s clarify the differences and how we could use each other.
ResponseCache
First, the ResponseCache can be divided in 2 parts, that work independently and are different concepts of how and where the information would be cached. Let´s catch them up:
ResponseCacheAttribute: Basically it manipulates cache header like Vary, Cache-Control and others. It works telling the browsers or proxies to store (or not) the response content. This technique can reduce the number of requests done to the server, if used correctly.
The ResponseCache attribute sets response caching headers. Clients and
intermediate proxies should honor the headers for caching responses
under the HTTP 1.1 Caching specification
Response Caching Middleware: Basically it is used to make server side caching based on headers defined by ResponseCacheAttribute. Depending on the Request Headers sent to the server, the response would never be cached on server side.
Enables caching server responses based on HTTP cache headers.
Implements the standard HTTP caching semantics. Caches based on HTTP
cache headers like proxies do.
Is typically not beneficial for UI apps such as Razor Pages because
browsers generally set request headers that prevent caching. Output
caching, which is available in ASP.NET Core 7.0 and later, benefits UI
apps. With output caching, configuration decides what should be cached
independently of HTTP headers.
And at this point that OutputCache comes as a replacement for Response Caching Middleware.
OutputCache (available in ASP.NET Core 7.0 and later)
The OutputCache configuration decides what should be cached (server side) independently of HTTP headers. Also it comes with a lot of new features like cache entry invalidation, storage medium extensibility and others.
Conclusion
To take the benefits from both worlds you can use:
ResponseCacheAttribute: To manipulate response headers and enable the clients/proxies to store content on client side;
OutputCache: To store responses on server side and increase throuthput when responses are cached.
Both work independently. You can choose the one that fits best you application.
I haven't watch the video CodingMytra provided. But I think Output caching has some enhancements over Response caching. For example, you can specify a few seconds of caching.
I found a useful video, and it has some demos you learn more about the Output caching in .Net7. I think you can find the difference in this video.
We can find out why there is a need for Output caching in this github issue.
Link : Add support for Output Caching #27387
I am running a couple of .net core webapi behind a reverse proxy. I have gotten the Swagger UI to load the swagger json. However, the operations' paths in json document are not relative,which breaks the try it out feature of the SwaggerUI as request are sent to root. How would I go about making the request relative ?
Context:Currently using WCF Data Services 5.0 with Odata for a Windows 8 Store application.
Have been trying to compress the OData coming over the wire from my service today and running into plenty of issues surrounding support.
binary serialization isn't supported.
json isn't supported (library throws 'application/json' is currently not supported in Content-Type header)
json lite isn't released yet
adding gzip requests in the http response works (server returns compressed) - but client side lib doesn't seem to want to deserialize it. (xml parsing exceptions)
My final attempt today was to try and get a hold of the http response, and to manually deserialize the stream myself (GZipStream isn't available but i know there are 3rd party alternatives) - but I couldn't find ANY Microsoft.Data.Services.Client.WindowsStore events/overrides that would expose the stream to me.
I wanted to implement OData to leverage the performance and efficiency gains over standard WCF Web services - but with no way to compress the stream over the wire i don't get any.
Does anyone have any experience with this, or advice of how to approach?
Have you followed the same steps here to get json response.The client has to send MaxDataServiceVersion header:
http://blogs.msdn.com/b/astoriateam/archive/2012/04/11/what-happened-to-application-json-in-wcf-ds-5-0.aspx
I also checked that Odata 5.1.0 has been released on nuget. This has the better json support:
https://nuget.org/packages/Microsoft.Data.Services/5.1.0
Your other option is to use asp.net web api and try the odata support:
http://www.nuget.org/packages/Microsoft.AspNet.WebApi.OData
I'm new to WCF RESTFull services developpment and I'm looking for some usefull information and your experience feedback about using webHttpBinding compared to the new WCF Web API http://wcf.codeplex.com/.
What I'm looking for is to know about the shortcomings of webHttpBinding and therefore why to use the new Web api and especially what problems the new API resolves.
If you could point me to some blog posts comparing both of them or just talking about the problems when using webHttpBinding I would appreciate. Thank you in advance.
Main shortcomings I would say is that the webhttpbinding makes it difficult to handle HTTP specific concerns. It works great if all you are doing is passing an object over HTTP that is serialized into XML or JSON and which may be transported over different formats.
HTTP is much more than a simple transport protocol for XML and JSON, it is an application layer protocol with rich semantics. Web API is specifically targetting folks that want to build systems over HTTP that fully levergage HTTP's richness.
Web API embraces that HTTP Resources can have a multitude of representations based on the needs of different clients. One end of the spectrum could be a dumb browser that just talks to a service using a Form url encoded post and a GET, while the other end could be a more rich client that uses Atom/OData or a hypermedia based media type.
Web API embraces that there are other HTTP specific concerns like conneg, etags, etc which allow better leveraging intermediary web servers.
Web API is designed with more testability in mind, thus you can address working with HTTP messages or other concerns in a more testable manner.
Web API has a more simplified configuration story.
You can read more about the rationale here: http://blogs.msdn.com/b/endpoint/archive/2010/11/01/wcf-web-apis-http-your-way.aspx
The most significant difference for me is the change in programming model. You no longer write 'services' which expose 'operations' bound to HTTP idioms (GET, POST etc.). With Web APIs you create 'resources' (POCOs) with which your clients can interact.
Web APIs seem to be better at handling various custom media types (like PNG images for example).
Last but not least, Web APIs are far better suited for automated testing. For instance, you no longer have to use static context classes to access HTTP concepts such as response codes. You use POCO request and response classes which can be easily instantiated in automated tests using old-style new() operator.
I agree with Ladislav that Web APIs are just a preview now and building application on top of it can be both risky and forbidden by the means of license agreement (but I haven't checked that).
Have you considered #serialseb's OpenRasta? It is stable and offers very nice programming model for building RESTful services.
The Web API is something like possible future of REST development in WCF. It is just preview which can significantly change before final release (probably in next version of .NET framework). So if you want to build production REST service you should use webHttpBinding.
Available information about Web Api can be found for example on .NET Connected Framework team's blog and on the site you mentioned. It is simplification and extension of current REST API.
Web API provides a REST-friendly HTTP based API. Web API uses the patterns of MVC and is going to be very familiar to ASP.NET MVC developers. Web API can leverage the capabilities of HTTP as an application layer protocol, returning resources in multiple representations (XML, JSON, HTML etc.) according the the client's request headers.
On the other hand WCF webHttpBinding uses the patterns of WCF, and is going to appeal more to the WCF developer - ServiceContracts, OperationContracts, comprehensive (or overweight, depending how you look at it, config file), ability to self-host outside of IIS.
One of the things I like about Web API is the ability to use dynamic types to escape the constraints of the type system. I also like the default exception behavior in Web API - contrast WCF webHttpBinding where, by default, exceptions bubble up as HTTP 500 + an HTML payload (yuk!).
Its nice to have the choice between two excellent technologies here. I wouldn't describe Web API as 'newer' or 'better' that WCF, as this implies its a replacement technology and that WCF webHttpBinding is legacy, which I don't believe is true.
I chose to use WCF webHttpBinding recently to expose a JSON API for an existing WCF SOAP service. I believe it was a good choice because it fitted that style of that existing solution and minimized the amount of change required.
I've build a WCF Service to accept a file and write it to disk. The front-end consists of a page with SWFUpload which is handling the upload on the client side. Apparently, SWFUpload posts the data with a Content Type of: multipart/form-data.
I would think this ok but on the Service side I get an error. The error is "ProtocolException" expecting text/xml. I've tried different message encodings in the bindings but nothing seems to work.
How can I get this file uploaded using multipart/form-data?
#jdiaz,
#JasonS is right, to upload file you need to transfer it as a byte stream. You need to use WCF streaming. For example on how to upload file via WCF see an article from http://kjellsj.blogspot.com
What you want to use is probably MTOM, if you want it to be standard. Using this, you can have MIME multiparts messages.
You then have to read the file as a stream and stuff it into one of the parameters of the request.
It might be that your WCF service targets .NET Framework 3.5 and your IIS is running on .NET Framework 4.0. In this case (framework mismatch) you need to modify your service.
I believe you are going to have to tranfer the file as a byte array to WCF. You will need to handle the post from SWFUpload and convert to a byte array before sending to your service.