Do I even need this rule anymore?
I don't see any requests incoming for resource.axd files (as opposed to when I ran webform applications)
WebResource.axd is an HTTP Handler that is part of the .NET Framework
that does one thing and one thing only – it is tasked with getting an
embedded resource out of a DLL and returning its content. What DLL to
go to and what embedded resource to take are specified through the
querystring. For instance, a request to
www.yoursite.com/WebResource.axd?d=EqSMS…&t=63421… might return a
particular snippet of JavaScript embedded in a particular assembly.
Its still part of the framework and you can still retrieve embedded resources using the above handler. You dont want your route handler to handle such requests and that is why it is ignored. My guess is that you can get rid of it if you are completely sure that your app/libraries that you use dont use it.
Related
We are trying to use Cobalt (20.stable) browser as the browser of our web SPA application.
My requirement is to be able to change URL at runtime, what I was able to find in the code:
Is:
starboard::shared::starboard::Application::Link(const char* link_data)
which ends up sending:
kSbEventTypeLink
Unfortunately this is not working, as code is ignoring the call; the handling reaches the point:
// TODO: Remove this when terminal application states are properly handled.
if (deep_link_event->IsH5vccLink()) {
browser_module_->Navigate(GURL(deep_link_event->link()));
}
In my case I m trying to change the URL to let say https://www.example.com.
There should be a way to do that as when navigating we can always have a link that will cause the browser to go to some URL?
Porting layer is not supposed to control navigation directly. Instead, your Starboard implementation may send a deep link event which could be intercepted by a web app which will perform a navigation. See h5vcc_runtime.idl for Web API.
That said, if you are building an SPA, why do you even need to change a URL? Initial URL of a web app is controlled by --url command line switch.
When you say runtime are you looking to change the initial URL when the app is first launched? If so, you could just use the --url parameter.
So you could do the following:
cobalt --url="https://www.example.com"
I did a patch to allow changing the URL.
I just need to call starboard::shared::starboard::Application::Link("https://www.example.com").
Inside this call a DeepLinkEvent is posted.
Patch : https://gofile.io/?c=9GvNHX
Cobalt does not navigate for you. The JavaScript receives the deeplink with the function it sets on h5vcc.runtime.onDeepLink and then does whatever it wants with that. As a SPA, it will parse the URL and load new content from its server in its own internal data format (e.g. protocol buffers, JSON, etc.) which it uses to update its own DOM to show new content.
Navigating is not the point of a SPA since that makes it not be a single page application. However, there may be cases such as a loader app that will want to make some initial decisions then load the actual SPA. That loader app would have to have the appropriate CSP rules in place, then set window.location to the URL of the page to navigate to.
Note: The code you found in Application::OnDeepLinkEvent() is a remnant that previously supported the H5vccURLHandler, which was removed in Cobalt 20. It's not meant to navigate to arbitrary deeplinks.
To update the resource i have exposed following reset web api url -
http://server.com/api/v1/{companyid}/resources/{resourceid}
and request body contains the resource to be updated.
I have also exposed a seperate API to update a property of same resource. From business rule perspective this is special property and cannot be updated/retrieved along with normal resource api.
So using following url to expose separate api as below -
http://server.com/api/v1/{companyid}/resources/{resourceid}/property?propertyKey=propertyValue
this does not sound good. Is there better approach?
Answer from the comments for others
PUT api/v1/{companyid}/resources/{resourceid}/{property} with the Body containing the value of the property is one way.
PUT api/v1/{companyid}/resources/{resourceid}/{property}/{propertyvalue} is another way if you want the value entirely in the URL.
Of course, http://server.com/api/v1/{companyid}/resources/{resourceid}/property?propertyKey=propertyValue is also probably fine.
As #David-Brabant mentioned don't version your API's in the URL
I am trying to work out a way to provide a CSV download through a Spring 3 Portlet. I have a method that uses the #ResourceMapping annotation to define a handler that takes some report params in the form of a #ModelAttribute, builds the report, and returns it. The catch-22 I am running into is validating the parameters being send in from the client form.
If I make the handler a #ResourceMapping, I can set the headers and write out the report as using the ResourceResponse, but I can't seem to figure out how to redirect the user back to the Portlet view with errors when their input fails validation. However, if I make it an #ActionMapping, I can then check the BindingResults and forward them back to the form as needed, but the ActionResponse doesn't allow me to set the Content-Disposition header nor write out the CSV bytes, which is sort of critical for sending the report back.
I am at a total loss here, as I don't even know what my options are. Is it even possible to do what I am trying to do with a Portlet? Are there other examples I could look at for a possible work-around?
I suggest you to use both #ActionMapping and #ResourceMapping to fulfill your requirement.
As you said you were able to handle the validation errors using the #ActionResponse, I'll tell you how to handle the Resource Streaming.
As you know every #ActionResponse is followed by a #RenderResponse, just return the same view but, with a hidden iframe this time whose src points to the ResourceURL.
Now the Request you receive in #ResourceMapping is something which is already Validated. So, you can now serve your CSV.
I dont know how complex is your UI and if you are using jsp as views in your application. If nicely managed, Validation can be handled by #ResourceMapping.
Thank you
I am looking for a way to batch requests to the server. I found a post by Brad Wilson outlining how to make a batch handler using a message hanlder http://bradwilson.typepad.com/blog/2012/06/batching-handler-for-web-api.html#more but I wasn't able to get this working.
first I had compile errors because webapi did not understand "route-specific endpoint handler" like Brad's example used. there were also problems with the media type and/or formatter (can't remember which). My next attempt was to make a batch controller. so instead of a batch handler I had a batch controller. I almost has this working except when I used the MessageHandlerInvoker to call the individual commands I got exceptions about the additional handlers I have regsstered (1 for logging request/response and another to mimic user authentication).
At that point I stopped and reverted back to individual requests, not ideal, but it works.
My environment:
.net 4.0
VS 2010
mvc 4 front end (calls webapi)
webapi as a service tier
Has anyone else had any success with batched messages and webapi?
To be able to use per-route handlers you need ASP.NET Web API RTM which was only released yesterday (at the time when Brad wrote the article, it would only work with nightly MyGet feed builds or against Codeplex source).
You can get entire MVC4 RTM here or simply off Nuget.
I created an ASP.NET MVC4 Web API service (REST) with a single GET action. The action currently needs 11 input values, so rather than passing all of those values in the URL, I opted to encapsulate those values into a single class type and have it passed as Content-Body. When I test in Fiddler, I specify the verb as GET, and enter the JSON text in the "Request Body" input box. This works great!
The problem is when I attempt to perform Load Testing in Visual Studio 2010 Ultimate. I am able to specify the GET action and the JSON Content-Body just fine. But when I run the Load test, VS reports exceptions of type ProtocolViolationException (Cannot send a content-body with this verb-type) in the test results. The test executes in 1ms so I suspect the exceptions are causing the test to immediately abort. What can I do to avoid those exceptions? I'd prefer to not change my API to use URL arguments just to work-around the test tooling. If I should change the API for other reasons, let me know. Thanks!
I found it easier to put this answer rather than carry on the discussions.
Sending content with GET is not defined in RFC 2616 yet it has not been prohibited. So as far as the spec is concerned we are in a territory that we have to make our judgement.
GET is canonically used to get a resource. So you are retrieving this resource using this verb with the parameters you are sending. Since GET is both safe and idempotent, it is ideal for caching. Caching usually takes place based on the resource URI - and sometimes based on various headers. The point is cache implementations - AFAIK - would not use the GET content (and to be honest I have not seen any GET with content in real world). And it would not make sense to include the content in the key generation since it reduces the scalability of the caches.
If you have parameters to send, they must be in the URI since this is part of what defines that URI. As such, I strongly believe sending content with GET is wrong.
Even when you look at implementations such as OData, they put the criteria in the URI. I cannot imagine your (or any) applications requirements is beyond OData query requirements.