Is there any reason why a route would be properly mapped in one environment and not another? I am deploying the exact same routing information from my local development server to a production server, and the routes are not being evaluated the same.
I have downloaded Phil Haack's Routing Debugger, and it is confirming that the routes are matching locally, but not in production.
Has anyone ever experienced this?
UPDATE: I didn't include many details above. The production server is IIS 6 on Windows Server 2003. All my routes were working except for one that I was using as a custom image handler. The route I specified was mapping to a URL that ended with ".png"
I found that this was the problem with IIS 6 since it was not handing off the ".png" request off to ASP.NET. I added a wildcard mapping to the site and that fixed the problem.
I apologize for not having put more details before. Hope this helps someone else.
There's a couple of things at work. As you mentioned, IIS 6 doesn't hand off requests that aren't mapped to the ASPNET_ISAPI.dll. A wildcard mapping fixes that problem.
The other potential issue is that by default, routing doesn't route files that exist on disk. So if you make a request for a physical .png file, it won't get routed.
Related
I've written a REST server in Delphi XE (using the wizard) and I want to change the URLs a bit so that instead of having
http://192.168.1.84:8080/datasnap/rest/TServerMethods1/GetListings
I get something that looks more like http://192.168.1.84:8080/GetListings
Is there a nice easy of doing this?
The naming convention is (Delphi XE3):
http://my.site.com/datasnap/rest/URIClassName/URIMethodName[/inputParameter]
You can easily change the "datasnap" and "rest" part of the URL in the TDSHTTPWebDispatcher component properties. You can change the Class Name and Method Name of the URL by simply changing the name of your class and method. However, you still have to have 4 components to the URL, so for example it could be:
http://my.site.com/api/v1/People/Listing
See here:
http://docwiki.embarcadero.com/RADStudio/XE3/en/REST#Customizing_the_URL_for_REST_requests
You could put IIS or Apache in between to accomplish this, and indeed rewrite the URL to point to your service the way you like.
That provides some more advantages anyway (security and scalability mostly). For example, you can create a fail-safe setup with double servers, or you can create multiple machines with your service, and have your web server do the load balancing for example.
You'll get extra logging capabilities, and if you easily want to serve other web content it's easy to have a full fledged web server anyway.
URL rewriting is usually done in the web server configuration, in Apache using entries in the .htaccess file
Is it possible to get the Portal base URL (like http://www.thisismyportal.com) from a Portlet using Portlet 2.0 API?
Right now I'm planning to manually build it concatenating PorletRequest.getServerName(), PortletRequest.getServerPort() and PortletRequest.getContextPath(); but it seems kind of clumsy (and there's no PortletRequest.getProtocol())
While it is clumsy, it is the safest way to construct the URL; and while there is no PortletRequest.getProtocol() method, you can conclude the protocol using the PortletRequest.isSecure() method.
I would advise against using an external configuration for the base URL, for a couple of reasons.
First, it would be yet another configuration item for you to maintain across environments (test, integration, production and so forth). There's very little justification to hold, in configuration, something that is fully reproducible using the current request.
Second, under certain circumstances, it might be impossible to designate a particular URL as a "base URL" for the portal. An example would be the case in which the portal server is associated with multiple hosts, or multiple host aliases.
We had those configuration properties in Resource Environment Provider for the purpose of generating external URLs for sending them in emails. It was specific solution and it wasn't a problem for us as we had other properties stored there as well so we knew it will be available at runtime. I don't know if that suits your needs. It depends on your scenario.
Also, we used https only during login, so we always generated http URLs.
Hope this helps.
I downloaded the example application and was surprised to see quite complex web request building and handling.
Unfortunately I have not been able to find even one scrap of documentation about the service.
I tried using AddServiceReference in VS and svcutil.exe on the end points (both the http general one and the https region specific ones) which I found in the example project (again I couldn't find them listed anywhere on the web) and both seamed to find a wsdl of sorts which they both used to create wrapper classes. But neither one created an app.config
and no mater what kind of binding I set up for them, I can not get the client to communicate.
Is there any documentation for the service?
Is there a way to use it with WCF?
Thank you
Rabbi,
i have the same thing here, there are some non MS sites discussing this:
- http://www.britishdeveloper.co.uk/2012/05/export-and-back-up-your-sql-azure.html
- http://www.codeproject.com/Articles/287597/Sql-Azure-Import-Export-Service-bacpac-dac-Extract
There is also a DacSample site, but that doc is bit messed up, mixing the DAC client tools with the hosted solution. if i read the doc correctly and follow the links i end up going in circles. Not funny :)
Good luck!
Pete
I am modifying some legacy project using SOAP web services. I noticed that some of the URLs it is pointing to for some of the namespace are not working anymore (500). Any idea what the consequence would be?
Both the client and server seems to be working fine still, but I need to make a new client that consumes the WS.
Namespaces may be in the form of a URL, but they do not represent a resource on the network. In many cases, there never was any resource at that location. It makes no difference at all.
I am trying to do some cross-site in GWT.
According to GWT:Same Origin Policy I've added to the module xml file.
It is working okey as long as I am not calling any GWT remote service (using GWT-RPC), but when I try to call any remote service, I got no response!
Any one know how to fix cross-site issue in GWT with GWT remote services?
Thanks in advance!
Steve's answer is correct, however there is one other option you can consider which is the best approach if you want to require authentication for server interaction without using OAUTH. The main point is that the cross-site linker doesn't bypass the SOP, but allows you to host the index.html on a different site than the JS code so that you can have the JS code and servlets on one server and load them from another. To get around the SOP you can use a method called JSON with padding or JSONP. Essentially what it does is use a script tag to inject a foreign request into the environment by wrapping the requested data in a callback. To do this you can use one of many server-side implementations such as Jersey. GWT 2 includes a JsonpRequestBuilder object which does all the client-side work for you and can be used in the same way as RequestBuilder. See this article for a tutorial.
If you want to access some other server (example.com) from your GWT app, then you'll have to do an RPC to your server, and in your server-side code, you'll have to make another HTTP call to the example.com page you're looking for.
The page you linked to regarding cross-site linking outlines that adding <add-linker name="xs"/> to the module file allows you to split your hosting between 2 servers:
One server for static files (all GWT produced html and js files, and all images)
One server for dynamic calls (all your RPCs go here, and your index.html home page must be here)