I have a REST service that generates string messages with currencies and dates, so I need the right culture to be set up. Messages are produced in different steps that runs between asynchronous operations.
Web API will set the culture coming in the Accept-Language header if such feature is configured in the Web.config:
<globalization enableClientBasedCulture="true" uiCulture="auto" culture="auto" />
After some testing it seems that the culture got by Web API this way is consistent across async/await operations. I wonder if it will behave the same way when on self-host...
However, I would like to know how to change the culture of the request arbitrarily in a way that flows correctly in the SynchronizationContext used by the host. I think it should be possible because as I said, the one adquired from the Accept-Language header using enableClientBasedCulture="true" seems to flow correctly.
For example, AspNetSynchronizationContext flows it through HttpContext.Current, so if Thread.CurrentThread.CurrentCulture and/or Thread.CurrentThread.CurrentUICulture are manipulated, their culture may change after an await. So this way is not safe for async/await.
What I am looking for is not the culture awaiter from Stephen Toub, but the way of forcing Web API to change the request's culture to something else.
I have tried with a delegating handler, changing the Accept-Language in the request message, but it seems too late and it has no effect on Thread.CurrentThread.CurrentCulture and/or Thread.CurrentThread.CurrentUICulture.
Is there a way of doing this in a safe async/await way?
Related
So I've done quite a bit of reading on stackoverflow and found a lot of question about how to do cross domain calls with either ajax post or jsonp. I know how to do that in both ways but let's do a reality check:
AJAX Post, if I use phonegap to compile the package, cross domain call is automatically availability . Or iframe wrapper etc can be used to hack around the security constraint.
use JSONP format, it's HTTP GET but I get cross domain capability for free as that's what JSONP is for. The data to be posted will be passed as a parameter value instead of being a payload as in an HTTP POST request.
Now my question is that is there a best practice/preferred way among the two? Pros and Cons?
Personally I don't see a practical difference between two. i.e. in a non-encrypted request, both POST or GET expose everything in clear text anyway, so they are just same piece of text arranged in different formats. My main concerns are around extension to make the connection secure and spam proof but there could be other stuffs that I probably should be mindful about as well - educate me please! E.g. easeness to add HTTPS over SSL or if I want to restrict who can send request to my server. I'm new to web technology (i.e. defined standards, protocols, frameworks) but am reasonably experienced on general development/computer science topics.
I'm debugging some tricky Ajax code without a server side, in fact I have no domain etc to even put any server-side code on.
I would like to find some very minimal Ajax JSON(P) testing or debugging webservice or web API that just sends something back. Something like a ping or noop or ack.
I would prefer something small, fast, and reliable, preferably provided by major Internet companies such as Google, Microsoft, or Yahoo.
Ideally it would support these features, though none are totally essential:
Support JSONP.
Parametrically return success or various kinds of failure.
Parametrically delay a specified time before responding.
Parametrically support or reject CORS requests.
Parametric control over HTTP headers.
Parametrically describe the object returned.
In fact the most basic form of such a service from a major provider would also be useful for determining that Internet access is available, at least to a degree beyond navigator.onLine.
jsFiddle actually supports some of the features I'm looking for with their “Echo Javascript file and XHR requests”.
To improve user experience “echo” features has been created. This allows to test XHR requests, add javascript files, create workers - all from one fiddle, so it is more transparent for the user reading the code. XHR requests are split to HTML, JSON, JSONP and XML. Gist and github responses are similar to the echo feature and go nicely in pair with storing fiddles in gist and github.
They're not really intended for use outside jsFiddle though. Some limitations:
HTTP POST must be used for everything except JSONP and JavaScript.
CORS is not supported.
Of the desired features I listed, it supports at least:
specifying a delay
describing an object to return
There're two GET requests:
1) "usual"GET (involves reloading page).
2) ajax GET (sync, async) background request.
What is difference between them?? Does HTTP standard make a distinction bitween them??
No. There is no difference. Although some browsers, and some frameworks like jQuery send an additional header, so you can make a distinction if you like. Otherwise they are handled the same.
No, the HTTP standard makes no distinction between them. The distinction is applied at the browser level.
Fundamentally, the big difference is that a request via XMLHttpRequest (an "ajax" request) is subject to the Same Origin Policy. A normal GET is not. This means that in the normal case, you can't use a genuine "ajax" request to retrieve a resource from a different "origin" than the page on which your script is running. (Note that it's the origin of the page on which your script is running, not the origin of your script file, which can be from anywhere.)
There are ways in which "ajax" can be used even cross-origin:
Cross Origin Resource Sharing (CORS) is a new(ish) technology defined by the W3C and implemented by some browsers. It allows the resource being requested to make the decision of whether to allow itself to be used by the requesting document. Supported by the latest versions of all major browsers, though IE's support is broken requires that you use their proprietary XDomainRequest object rather than XMLHttpRequest.
JSON-P works around the restriction by not really being an "ajax" request at all; instead, it's a convention both the client and server observe that allows the client to include a script from the server via a script element. (The script in question is usually dynamically generated, and its sole job is to deliver a JavaScript object as a payload by calling a function.)
I've created a RESTful API that supports GET/POST/PUT/DELETE requests. Now I want my API to have a Javascript client library, and I thought to use JSONP to bypass the cross-domain policy. That works, but of course only for GET requests.
So I started thinking how to implement such a thing and at the same time trying to make it painless to use.
I thought to edit my API implementation and check every HTTP request. If it's a JSONP requests (it has a "callback" parameter in the querystring) I force every API method to be executed by a GET request, even if it should be called by other methods like POST or DELETE.
This is not a RESTful approach to the problem, but it works. What do you think?
Maybe another solution could be to dynamically generate an IFrame to send non-GET requests. Any tips?
There's some relevant points on a pretty similar question here...
JSONP Implications with true REST
The cross-domain restrictions are there for a reason ;-)
Jsonp allows you to expose a limited, safe, read-only view of the API to cross domain access - if you subvert that then you're potentially opening up a huge security hole - malicious websites can make destructive calls to your API simply by including an image with an href pointing to the right part of the API
Having your webapp expose certain functionality accessed through iframes, where all the ajax occurs within the context of your webapp's domain is definitely the safer choice. Even then you still need to take CSRF into consideration. (Take a look at Django's latest security announcement on the Django blog for a prime example - as of a release this week all javascript calls to a Django webapp must be CSRF validated by default)
The Iframe hack is not working anymore on recent browsers, do not use it anymore (source : http://jquery-howto.blogspot.de/2013/09/jquery-cross-domain-ajax-request.html)
In every MVC framework I've tried (Rails, Merb, Waves, Spring, and Struts), the idea of a Request (and Response) is tied to the HTTP notion of a Request. That is, even if there is an AbstractRequest that is a superclass of Request, the AbstractRequest has things like headers, request method (GET, POST, etc.), and all of the other things tied to HTTP.
I'd like to support a request-response cycle over SMS, Twitter, email, or any other medium for which I can make an adapter. Is there a framework that does this particularly well?
The only other option I've thought of is creating, for example, a Twitter poller that runs in a separate thread and translates messages into local HTTP requests, then sends the responses back out.
If there were a good framework for multiple request media, what would routing look like? In Rails, the HTTP routing looks something like:
map.connect 'some/path/with/:parameter_1/:paramter_2', :controller => 'foo', :action => 'bar'
How would a Twitter or SMS route look? Regular expressions to match keywords and parameters?
I haven't seen one. The issue is that the request is also tied to the host, and the response is tied to the request.
So if you get a request in via email, and a controller says to render view "aboutus", you'd need the MVC framework to know how to :
get the request in the first place - the MVC framework would almost need to be a host (IIS doesn't get notified on new emails, so how does your email polling code get fired?)
allow flexible route matching - matching by path/url wouldn't work for all, so request-specific controller routing would be needed
use the aboutus email view rather than the SMS or HTTP view named "aboutus"
send the response out via email, to the correct recipient
A web MVC framework isn't going to cut it - you'll need a MVC "host" that can handle activation through web, sms, email, whatever.
The Java Servlet specification was designed for Servlets to be protocol neutral, and to be extended in a protocol-specific way - HttpServlet being a protocol-specific Servlet extension. I always imagined that Sun, or other third poarty framework providers, would come up with other protocol-specific extensions like FtpServlet or MailServlet, or in this case SmsServlet and TwitterServlet.
Instead what has happened is that people either completely bypassed the Servlet framework, or have built their protocols on top of HTTP.
Of course, if you want to implement a protocol-specific extension for your required protocols, you would have to develop the whole stack - request object, response object, a mechanism of identifying sessions (for example using the MSISDN in an SMS instead of cookies), a templating and rendering framework (equivalent of JSP) - and then build an MVC framework on top of it.
You seem to be working mostly with Java and/or Ruby, so forgive me that this answer is based on Perl :-).
I'm very fond of the Catalyst MVC Framework (http://www.catalystframework.org/). It delegates the actual mapping of requests (in the general, generic sense) to code via engines. Granted, all the engine classes are currently based on HTTP, but I have toyed with the idea of trying to write an engine class that wasn't based on HTTP (or was perhaps tied to something like Twitter, but was separated from the HTTP interactions that Twitter uses). At the very least, I'm convinced it can be done, even if I haven't gotten around to trying it yet.
You could implement a REST-based Adapter over your website, which replaces the templates and redirects according to the input parameters.
All requestes coming in on api.yourhost.com will be handled by the REST based adapter.
This adapter would allow to call your website programmatically and have the result in a parseable format.
Practically this means: It replaces the Templates with an own Template Engine, on which this things happen:
instead of the assigned template, a generic xml/json template is called, which just outputs a xml that contains all template vars
then you can make your Twitter Poller, SMS Gateway or even call it from Javascript.