I'm using a library that is submitting a "POST" request to a .axd path in my Angular application. Since I am using UI-Router, it seems that the #/ appended to the URL is preventing the request from properly reaching the DLL.
The URL that needs to be reached in the library is:
http://localhost:8080/MyApplication/MyArea/ModuleName#/ThermalLabelWebEditor.axd?_=1478731762000
However, all I am getting back from this "POST" request is the HTML data of the page. I believe this is a symptom of MVC handling the path in its default manner, searching for a page matching the above URL, rather than accessing the DLL.
What I am trying to achieve is something along the lines of
routes.IgnoreRoute("{*anything}/ThermalLabelWebEditor.axd/{*pathInfo}");
However, this is not valid in MVC.
Additionally, I've specified in my Area's Web.config file the httpHandlers required for this library, mainly:
<system.web>
<httpHandlers>
<add path="ThermalLabelWebEditor.axd" verb="*" type="Neodynamic.Web.ThermalLabelEditor.ThermalLabelWebEditor"/>
...
<system.webServer>
<handlers>
<add name="TLWE" path="ThermalLabelWebEditor.axd" verb="*" preCondition="integratedMode" type="Neodynamic.Web.ThermalLabelEditor.ThermalLabelWebEditor" />
Now, I know that I can specify $locationProvider.html5Mode(true); in my Angular module's configuration. However, I would like to avoid doing this if at all possible, as it wouldn't solve the problem for older, non-HTML5 browsers that have to use the # fallback.
How can I configure my Web.config file for this Area (or for the entire MVC application) or the RouteConfig.cs to ensure that the request to ThermalLabelWebEditor.axd will successfully complete?
I'm using MVC 5, .NET 4.6, Angular 1.5.8, and UI-Router v0.3.1.
After much investigation, I have determined that this issue is only fixable on the JavaScript side. There appears to be no way to get IIS to parse # in the path section of the HTTP Handler, even with the use of wildcards. Due to the nature of how the # will short-circuit the URL, IIS is unable to route the request to the HTTP Handler, therefore handling the response instead with standard MVC that is breaking the application. Similarly, even with routes.IgnoreRoute, MVC cannot be configured to interpret the # character.
The solution to this issue is really just to parse the URL before sending the request and removing the #. With this in place, the handler mappings can be configured to look at the route in question MyArea/MyModule/HttpHandler.axd... and intercept with IIS before looking through the MVC structure.
I should note that the reason I am avoiding the use of HTML5 Mode in UI-Router is to preserve browser compatibility. If HTML5 Mode were enabled, the issue would be fixed for HTML5-compliant browsers. However, non-HTML5 browsers will fallback to the # in the URL, thus breaking the application.
Related
Im am trying to call a rest post service from my Camel route.
The rest service is deployed at https://csp-verteileauftrag-camunda-v1-csp-ims-dev-az.apcn.osp4-preprod.hel.kko.ch/api/v1/verteileauftrag/.
Calling the Service from a Rest Client like VS Code works if there is a trailing slash (after verteileauftrag).
In my camel route I have configured the following:
restConfiguration().host("https://csp-verteileauftrag-camunda-v1-csp-ims-dev-az.apcn.osp4-preprod.hel.kko.ch/api/v1").component("http").bindingMode(RestBindingMode.json);
and in then later using the config:
.to("rest:post:verteileauftrag?outType=ch.helsana.csp.verteileauftrag.rest.model.apiadapter.ResponseType")
If I execute the code, I get a 404 HTTP Error from the Backend as the URL used is
https://csp-verteileauftrag-camunda-v1-csp-ims-dev-az.apcn.osp4-preprod.hel.kko.ch/api/v1/verteileauftrag. So without a trailing slash.
I have tried to add it like .to("rest:post:verteileauftrag/?outType=ch.helsana.csp.verteileauftrag.rest.model.apiadapter.ResponseType")
but no success.
Do you have any idea how to tell the http component in the rest configuration how to add the trailing slash?
Thank you very much.
Using redhat fuse 7_10_2.
Regards Michel
Based on a collegues example I reimplemented the Rest Service call with a normal .to("URL") configuration in the routebuilder with setting the appropriate Headers for HTTP Post and content type json. Would still be interessted in any answer, but not waiting on one.
I am getting this error when my payment gateway is redirecting user to my react application. Same code works on firebase hosting and doesn't give the error. Redirection url is a POST request
I tried various solutions from Asp.NET Web API - 405 - HTTP verb used to access this page is not allowed - how to set handler mappings
removed WebDav
Assuming there is no CORS issue here.
The issue is the call back to your site is a Post request along with data. Client application's index.html hosted inside IIS is not able to understand how to handle a post request to a html page. You will have to specifically make an entry in Handler Mapping section of IIS configurations.
Inside Request Restrictions add the HTTP Methods you want it for or allow all verbs if it is a specific case.
Or you can directly put it in your web.config with what all verbs you want to allow, as in below snippet
<add name="html" path="*.html" verb="*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="Unspecified" requireAccess="None" />
On the Request Filtering page, switch to the "HTTP Verbs" tab - if you see that "POST" has "Allowed" set to False, this is the cause. Remove this entry or changing it to explicitly be allowed will fix the issue.
My app's frontend is done in Angular while the backend is in PHP. For this last reason, I am using Apache as app server.
I want to use Angular's routing feature, that is, $routeProvider.when(), with conditional params (aka named groups) such as /user/:id/, where :id would be a parameter passed to the controller specified in the route.
Obviously, Apache tries to handle the request e.g., /user/21 by looking for a resource called 21 inside of the user directory, and thus returns a 404 error, instead of letting Angular routing load the resource at /user and using the value 21 to do internal stuff (such as calling an API).
How would I have to setup Apache so that some requests are left to be handled by Angular?
Please look at this page
(https)[url]/cart
and compare with
(http)[url]/cart
You will notice the console errors on the secure version and there are no console errors in the insecure version. I am using Angular custom directives they are not resolving over the secure protocol. My assumption would be there is a resource which is being blocked?? However I cannot find this resource... any ideas?
I have also tested this locally with a self signed certificate and it works fine.
The problem is this partial is entirely different between your http and https server:
/partials/bonuses.html
The https version of bonuses is just a page with a script that sets the window.location to the non-https version. As far as I know, you cannot put an html tag as a directive's template, and that's why angular is throwing up errors. It wouldn't make any sense to do that anyway.
You need to make sure that the https server serves the full bonuses.html partial, and not just a redirect to http
The Problem
When uploading a file using the Go Blobstore API, the success path redirects to the wrong appengine module. Here is a more visual description of the problem:
User lands on the upload page of module A: http://A.my-appengine-app.com/upload
User's browser makes a request to the module for an upload session: http://A.my-appengine-app.com/upload/session
Module A defines a handler for /upload/session which runs the following Go code: url, err := blobstore.UploadURL(c, "/upload/success")
The method returns a URL, similar to: http://A.my-appengine-app.com/_ah/upload/[some long hash]/
This URL is relayed back to the user's browser and inserted into the action of a <form>.
The user submits a multipart POST request to the URL
Whatever handles the URL (some non-user-space appengine handler), attempts to redirect back to /upload/success
This is where things get weird. In development, the server redirects to "/upload/success" in module A. In production, the server redirects to the main module, which we can call B for now. I can tell this is happening because I am getting a 404 in my web console and the logs indicate that the request is being made to module B. I've even gone so far as to explicitly pass the hostname as part of the success path (step #3), but to no effect.
Current Solution (Not Ideal)
It seems my only recourse is to define a handler in module B to handle the request as module A would. Since the goapp architecture globs all the modules together, this isn't the worst tradeoff in the world, but it's semantically wrong given that modules are supposed to be vertically independent. If anyone has any idea how to work around this, I'd be obliged. For now, I'll take the aforementioned approach.